Open source system framework layer custom interface authentication method, equipment and medium

Abstract

The invention discloses an open source system framework layer custom interface authentication method comprising the following steps: creating a custom service in an open source system framework layer, the custom service providing at least one custom interface; establishing an encrypted and stored authentication white list file, wherein the encrypted and stored authentication white list file comprises a package name and signature fingerprint information of an application needing to be authorized; integrating an authentication trigger mechanism in the custom interface, and executing a hierarchical authentication process when an external application calls the custom interface; the hierarchical authentication process comprises the following steps: acquiring a package name of a calling party application and checking whether the package name exists in an authentication white list file or not; if yes, signature fingerprint information of the calling party application is further obtained and compared with fingerprints recorded in the authentication white list file; and if the fingerprints are consistent, the authentication is successful, and the function logic of the user-defined interface is executed. According to the method provided by the invention, the custom interface is ensured to be only open to the authorized application through a dual verification mechanism of the package name and the signature fingerprint information, and the full choice and stability of the system are ensured.

Description

Technical Field

[0001] The present application relates to the field of interface management technology, and more specifically, to a method, device, and medium for customizing interface authentication at an open source system framework layer. Background Art

[0002] The framework layer of open source systems (Android, Hongmeng, etc.) is a bridge for upper-layer applications to communicate with underlying hardware. It is responsible for providing application software with a stable, standardized, and easy-to-use modular interface to enable the application layer to operate underlying hardware devices, such as cameras, flashes, and sensors.

[0003] Customizing open source systems often requires developing and implementing custom interfaces within the framework layer to facilitate application differentiation and specificity, emphasizing the product's functional characteristics. However, due to the nature of open source systems, if unrestricted, third-party applications can invoke custom interfaces through reflection, directly controlling system functions and posing a threat to device operational and data security. Therefore, it is necessary to introduce an authentication mechanism.

[0004] Authentication refers to verifying whether the user has the right to access the system. Local authentication in the prior art is to obtain the user's access request to the interface, query the authentication file based on the identifier of the current interface, compare the target user and the target access range, and confirm the authentication result. However, due to its complex interface identification, its authentication needs to compare the interface identification, target user and target access range, resulting in a long authentication link, a long time consumption, and inconvenience for the expansion of new interfaces. Network authentication in the prior art is to make a network request on the network server when calling the interface, and the server returns the authentication interface to the device. However, this authentication method needs to rely on the network, offline devices cannot be authenticated, the usage scenarios are limited, and there is a risk of network data being captured and parsed. Summary of the Invention

[0005] In response to at least one defect or improvement need in the prior art, the present application provides an open source system framework layer custom interface authentication method, system, device and medium, which are used to overcome the defects of the existing authentication methods, and only allow specific applications to call custom interfaces, ensuring that custom interfaces are only open to authorized applications, and ensuring the full selectivity and stability of the system.

[0006] To achieve the above objectives, in a first aspect, the present application provides an open source system framework layer custom interface authentication method, comprising:

[0007] Creating a custom service in the open source system framework layer, wherein the custom service provides at least one custom interface;

[0008] Establish an encrypted authentication whitelist file, which includes the package name and signature fingerprint information of the application that needs to be authorized;

[0009] Integrate an authentication trigger mechanism in the custom interface to execute a hierarchical authentication process when an external application calls the custom interface;

[0010] The hierarchical authentication process includes:

[0011] Get the package name of the calling application;

[0012] Verify whether the package name of the caller application exists in the authentication whitelist file. If not, the authentication fails. If so, further obtain the signature fingerprint information of the caller application and compare it with the fingerprint recorded in the authentication whitelist file;

[0013] If the fingerprints are consistent, the authentication is successful and the functional logic of the custom interface is executed; if the fingerprints are inconsistent, the authentication fails.

[0014] Furthermore, establishing an encrypted and stored authentication whitelist file includes:

[0015] Receive the package name of the application that needs to be authorized and the corresponding signature fingerprint information provided by the caller; the package name of the application can be determined in advance, and the signature fingerprint information can be obtained when the system is signed;

[0016] The authentication whitelist file is encrypted and stored in a specified path of the system partition;

[0017] The encryption algorithm uses the IDEA encryption mode, and the key length is not less than 128 bits.

[0018] Furthermore, verifying whether the package name of the caller application exists in the authentication whitelist file includes:

[0019] Obtain the full package name of the calling application through the open source system package management interface;

[0020] Verify that the complete package name is fully matched with the records in the authentication whitelist file;

[0021] If there is no match, an authentication failure response code is generated and subsequent operations are terminated.

[0022] Furthermore, the signature fingerprint information of the caller application is compared with the fingerprint recorded in the authentication whitelist file, including:

[0023] Obtain the digital certificate data of the caller application through the open source system package management interface;

[0024] Perform SHA-256 hash operation on the digital certificate data to generate the current signature fingerprint;

[0025] Perform fingerprint byte-level comparison. If the matching threshold reaches the preset ratio, the fingerprint comparison verification is considered successful.

[0026] Furthermore, it also includes a whitelist file update mechanism;

[0027] The whitelist file update mechanism includes an offline update method and / or an online update method;

[0028] Offline update mode: receive the encrypted authentication whitelist file update package through the physical interface, verify the device digital signature and replace the old file;

[0029] Online update mode: download the encrypted authentication whitelist file update package from the authorization server, verify the legitimacy of the digital certificate chain and decrypt it before it takes effect.

[0030] Furthermore, it also includes authentication optimization strategies;

[0031] The authentication optimization strategy includes:

[0032] Establish a memory cache table to cache the package name and signature fingerprint information of successfully authenticated applications;

[0033] Repeated call requests within the cache validity period directly return the authentication success status.

[0034] Furthermore, it also includes exception handling procedures;

[0035] The exception handling process includes:

[0036] When the number of consecutive authentication failures reaches the preset threshold, the system security policy is triggered to block the calling process;

[0037] Generates encrypted audit logs and stores them in a secure storage partition. The encrypted audit logs include timestamps, package names, and abnormal fingerprint fragments.

[0038] In a second aspect, the present application provides an open source system framework layer custom interface authentication system, including:

[0039] A framework layer service module, used to create a custom service in the open source system framework layer, wherein the custom service provides at least one custom interface;

[0040] A whitelist management module is used to establish an encrypted authentication whitelist file, which includes the package name and signature fingerprint information of the application that needs to be authorized;

[0041] An authentication execution engine, configured to integrate an authentication trigger mechanism into the custom interface and execute a hierarchical authentication process when an external application calls the custom interface;

[0042] The hierarchical authentication process includes:

[0043] Get the package name of the calling application;

[0044] Verify whether the package name of the caller application exists in the authentication whitelist file. If not, the authentication fails. If so, further obtain the signature fingerprint information of the caller application and compare it with the fingerprint recorded in the authentication whitelist file;

[0045] If the fingerprints are consistent, the authentication is successful and the functional logic of the custom interface is executed; if the fingerprints are inconsistent, the authentication fails.

[0046] In a third aspect, the present application provides an electronic device comprising at least one processing unit and at least one storage unit, wherein the storage unit stores a computer program, and when the computer program is executed by the processing unit, the processing unit is enabled to perform the steps of the custom interface authentication method described in any one of the preceding items.

[0047] In a fourth aspect, the present application provides a storage medium storing a computer program executable by an access authentication device. When the computer program runs on the access authentication device, the access authentication device is enabled to execute the steps of any of the aforementioned custom interface authentication methods.

[0048] In general, the above technical solutions conceived by this application can achieve the following beneficial effects compared with the existing technology:

[0049] (1) This application sets up a custom interface, which ensures that the custom interface is only open to authorized applications through a dual verification mechanism of package name and signature fingerprint information, reducing the risk of unauthorized access and ensuring the full selection and stability of the system.

[0050] (2) The whitelist update mechanism of the present application may include an offline update method and / or an online update method, thereby eliminating the need to rely entirely on the network and expanding the application scenarios.

[0051] (3) This application sets up a memory cache mechanism. The setting of the memory cache table reduces the repeated authentication response time from 45ms to less than 1ms, meeting the performance requirements of microservice authentication in high-concurrency scenarios.

[0052] (4) This application sets up an exception handling process, which can trigger the system security policy to block the calling process when continuous authentication fails, and then combine it with the encrypted storage of audit logs to meet the requirements of industrial-level security audits. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0054] Figure 1 A core flow chart of a custom interface authentication method for an open source system framework layer provided in an embodiment of the present application;

[0055] Figure 2 A full flow chart of a custom interface authentication method for an open source system framework layer provided in an embodiment of the present application;

[0056] Figure 3 A block diagram of an electronic device suitable for implementing the custom interface authentication method described above, provided in an embodiment of the present application. DETAILED DESCRIPTION

[0057] In order to make the purpose, technical solutions and advantages of this application more clearly understood, the present application is further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are merely for the purpose of explaining this application and are not intended to limit this application. In addition, the technical features involved in the various embodiments of this application described below may be combined with each other as long as they do not conflict with each other.

[0058] The terms "including" or "having" and any variations thereof in the specification, claims, or drawings of this application are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units that are not listed, or may optionally include other steps or units inherent to the process, method, product, or apparatus.

[0059] As described in the background technology section of the specification, local authentication in the prior art is to obtain the user's access request to the interface, query the authentication file based on the identifier of the current interface, compare the target user and the target access range, and confirm the authentication result. However, due to its complex interface identification, its authentication needs to compare the interface identification, target user and target access range, resulting in a long authentication link, a large time consumption, and inconvenience for the expansion of new interfaces. Network authentication in the prior art is to make a network request on the network server when calling the interface, and the server returns the authentication interface to the device. However, this authentication method needs to rely on the network, offline devices cannot be authenticated, the usage scenarios are limited, and there is a risk of network data being captured and parsed. In view of this, the present application provides an open source system framework layer custom interface authentication method, system, device and medium for overcoming the defects of the existing authentication method, realizing that only specific applications are allowed to call the custom interface, ensuring that the custom interface is only open to authorized applications, and ensuring the full selectivity and stability of the system.

[0060] Common open source systems include Android system, Hongmeng system, etc. An embodiment of this application is described using Android system as an example. Figure 1 and Figure 2 ,A method for custom interface authentication in the Android system framework layer may include the following steps.

[0061] Step 1: Create a custom service in the Android system framework layer, where the custom service provides at least one custom interface.

[0062] Specifically, create CustomAuthService in the frameworks / base / services / core / java / com / android / server / path, inherit the SystemService class to implement the Binder cross-process communication interface, and register the custom interface ICustomInterface.aidl to define the authentication callback method.

[0063] Step 2: Create an encrypted authentication whitelist file, which includes the package name and signature fingerprint information of the application that needs to be authorized.

[0064] Specifically, the caller receives the package name of the application requiring authorization and the corresponding signature fingerprint information. The application package name can be determined in advance, and the signature fingerprint information can be obtained during system signing. More specifically, an authentication whitelist file is created to record the package name and SHA-256 signature fingerprint information of the application requiring authorization. The application package name is known, and the SHA-256 signature fingerprint information can be obtained during system signing. Both pieces of data are provided by the application developer.

[0065] The authentication whitelist file is encrypted and stored in a specified path on the system partition. More specifically, the created authentication whitelist file is encrypted using IDEA (with a key length of no less than 128 bits) and preinstalled in a specific device program path. Whitelist file format: JSON structure {"pkg":"com.example.app","sig":"a1b2c3..."}. Encryption method: Using the IDEA algorithm, the key is stored in the hardware-encrypted area / sys / keymaster / secure_key. File storage path: / system / etc / auth_whitelist.enc.

[0066] Step 3: Integrate an authentication trigger mechanism into the custom interface. When an external application calls the custom interface, a hierarchical authentication process is executed. Software engineers develop custom services, provide custom interfaces, and call authentication interfaces in the custom interfaces, so that authentication is triggered when the custom interfaces are called. The hierarchical authentication process includes:

[0067] First, the application calls the interface provided by the custom service.

[0068] Custom services have limited call authentication interfaces.

[0069] The authentication interface obtains the full package name of the calling application through the Android system package management interface.

[0070] Verify whether the complete package name of the caller application exists in the authentication whitelist file, that is, perform a string complete match verification on the complete package name and the record in the authentication whitelist file. If not, the authentication fails, an authentication failure response code is generated, and subsequent operations are terminated. If it exists, the digital certificate data of the caller application is obtained through the Android system package management interface, and a SHA-256 hash operation is performed on the digital certificate data to generate the current signature fingerprint information. Then, the signature fingerprint information of the caller application is compared with the fingerprint recorded in the authentication whitelist file at the byte level. If the matching threshold reaches 100%, the authentication is successful; otherwise, the authentication fails.

[0071] After successful authentication, the custom interface is called to trigger its function implementation logic and complete the call.

[0072] Specifically, the package name verification component of the authentication execution engine calls PackageManager.getPackageUid() to verify the application identity; the signature verification component obtains the original certificate data through Signature.toByteArray(); and the decision engine implements the AuthDecisionTree class to handle multi-level verification logic.

[0073] This application sets up a custom interface. Through the dual verification mechanism of package name and signature fingerprint information, it ensures that the custom interface is only open to authorized applications, reducing the risk of unauthorized access and ensuring the full selection and stability of the system. This application uses IDEA encrypted storage of whitelist files (key length ≥ 128 bits) and 100% matching verification of signature fingerprints to effectively prevent man-in-the-middle attacks and data tampering, ensuring the integrity of authorized data.

[0074] In some embodiments of the present application, the custom interface authentication method may further include a whitelist update mechanism, which includes an offline update method and / or an online update method.

[0075] Offline update mode: receive the encrypted authentication whitelist file update package through the physical interface, verify the device digital signature and replace the old file.

[0076] Online update mode: download the encrypted authentication whitelist file update package from the authorization server, verify the legitimacy of the digital certificate chain and decrypt it before it takes effect.

[0077] The whitelist update mechanism of this application can include offline update mode and / or online update mode, thus eliminating the need for complete reliance on the network and expanding the application scenarios. Dynamic loading of whitelist files enables uninterrupted service updates, and system availability can reach 99.99%.

[0078] In some embodiments of the present application, the custom interface authentication method may further include an authentication optimization strategy. The authentication optimization strategy includes:

[0079] Create a memory cache table to cache the package name and signature fingerprint information of successfully verified applications.

[0080] Repeated call requests within the cache validity period directly return the authentication success status.

[0081] After technical verification, the initial authentication time was 45.2ms both without and with caching. For repeated authentication, the time without caching was 38.7ms, while with caching, the time dropped to 0.8ms. This application incorporates a memory caching mechanism. The configuration of the memory cache table reduces the repeated authentication response time from 45ms to under 1ms, meeting the performance requirements of microservice authentication in high-concurrency scenarios.

[0082] In some embodiments of the present application, the custom interface authentication method may further include an exception handling process. The exception handling process includes:

[0083] When the number of consecutive authentication failures reaches the preset threshold, the system security policy is triggered to block the calling process.

[0084] Generates encrypted audit logs and stores them in a secure storage partition. The encrypted audit logs include timestamps, package names, and abnormal fingerprint fragments.

[0085] This application sets up an exception handling process, which can trigger the system security policy to block the calling process when continuous authentication fails, and then combine it with encrypted storage of audit logs to meet the requirements of industrial-level security audits.

[0086] In some embodiments of the present application, the custom interface authentication method can be applied to the following scenarios.

[0087] *Scenario 1: Vehicle system command authentication

[0088] Key interface: VehicleControlInterface.setEngineState().

[0089] Whitelist configuration: Only ECU control applications with the package name com.auto.ecu and a matching signature fingerprint are allowed to call.

[0090] Security policy: Three consecutive authentication failures will trigger a CAN bus communication lock.

[0091] *Scenario 2: Offline authorization of industrial equipment

[0092] Deployment environment: AGV scheduling system without network connection.

[0093] Update mechanism: Update the encryption whitelist through physical contact with the NFC chip.

[0094] Data protection: Whitelist files are bound and encrypted with device serial numbers.

[0095] *Scenario 3: Financial terminal security call

[0096] Hardware support: Integrated HSM module to verify signature fingerprint.

[0097] Performance optimization: Create a ConcurrentHashMap to cache the last 10 successful authentication records.

[0098] Audit trail: Writes operation logs to tamper-resistant eMMC storage.

[0099] The whitelist field in this application supports permission level expansion, which can be smoothly connected to the RBAC permission model. The versatility of this system architecture has also been verified in vehicle network command control (Scenario 1) and financial terminal authentication (Scenario 3).

[0100] Another embodiment of the present application provides an Android system framework layer custom interface authentication system, which may include components or parts such as a framework layer service module, a whitelist management module, and an authentication execution engine.

[0101] The framework-layer service module is used to create a custom service in the Android system framework layer, providing at least one custom interface. The framework-layer service module creates CustomAuthService in the frameworks / base / services / core / java / com / android / server / path. It extends the SystemService class to implement the Binder inter-process communication interface. It registers the custom interface ICustomInterface.aidl and defines the authentication callback method.

[0102] Whitelist management module, used to establish an encrypted authentication whitelist file, which includes the package name and signature fingerprint information of the application that needs to be authorized. Whitelist management module:

[0103] Whitelist file format:

[0104] The JSON structure stores {"pkg":"com.example.app","sig":"a1b2c3..."}.

[0105] Encryption method: Use the IDEA algorithm, and the key is stored in the / sys / keymaster / secure_key hardware encryption area.

[0106] File storage path: / system / etc / auth_whitelist.enc.

[0107] The authentication execution engine is used to integrate the authentication trigger mechanism in the custom interface and execute the hierarchical authentication process when the external application calls the custom interface. The hierarchical authentication process includes:

[0108] Get the package name of the calling application;

[0109] Verify whether the package name of the caller application exists in the authentication whitelist file. If not, the authentication fails. If so, further obtain the signature fingerprint information of the caller application and compare it with the fingerprint recorded in the authentication whitelist file;

[0110] If the fingerprints are consistent, the authentication is successful and the function logic of the custom interface is executed; if the fingerprints are inconsistent, the authentication fails. Authentication execution engine:

[0111] Package name verification component: Call PackageManager.getPackageUid() to verify the application identity.

[0112] Signature verification component: Get the original certificate data through Signature.toByteArray().

[0113] Decision engine: Implement the AuthDecisionTree class to handle multi-level verification logic.

[0114] The specific technical details and technical effects of the Android system framework layer custom interface authentication system can be referred to the aforementioned embodiment of the Android system framework layer custom interface authentication method, which will not be repeated here.

[0115] Figure 3 A block diagram of an electronic device suitable for implementing the above-described custom interface authentication method according to an embodiment of the present application is schematically shown. Figure 3 The electronic device shown is only an example and should not limit the functions and scope of use of the embodiments of the present application.

[0116] like Figure 3 As shown, the electronic device 1000 described in this embodiment includes: a processor 1001, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage part 1008 into a random access memory (RAM) 1003. The processor 1001 may, for example, include a general-purpose microprocessor (such as a CPU), an instruction set processor and / or a related chipset and / or a special-purpose microprocessor (for example, an application-specific integrated circuit (ASIC)), and the like. The processor 1001 may also include an onboard memory for caching purposes. The processor 1001 may include a single processing unit or multiple processing units for executing different actions of the custom interface authentication method process according to an embodiment of the present application.

[0117] Various programs and data required for the operation of the electronic device 1000 are stored in the RAM 1003. The processor 1001, the ROM 1002, and the RAM 1003 are connected to each other via a bus 1004. The processor 1001 performs various operations of the process of the custom interface authentication method according to the embodiment of the present application by executing the programs in the ROM 1002 and / or the RAM 1003. It should be noted that the program can also be stored in one or more memories other than the ROM 1002 and the RAM 1003. The processor 1001 can also perform various operations of the process of the custom interface authentication method according to the embodiment of the present application by executing the programs stored in the one or more memories.

[0118] According to an embodiment of the present application, electronic device 1000 may further include an input / output (I / O) interface 1005, which is also connected to bus 1004. Electronic device 1000 may further include one or more of the following components connected to I / O interface 1005: an input portion 1006 including a keyboard, mouse, etc.; an output portion 1007 including devices such as a cathode ray tube (CRT), liquid crystal display (LCD), and speakers; a storage portion 1008 including a hard disk; and a communication portion 1009 including a network interface card such as a LAN card or modem. Communication portion 1009 performs communication processing via a network such as the Internet. A drive 1010 is also connected to I / O interface 1005 as needed. Removable media 1011, such as a magnetic disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed in drive 1010 as needed, so that computer programs read from the removable media can be installed into storage portion 1008 as needed.

[0119] The process of the custom interface authentication method according to an embodiment of the present application can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer-readable storage medium, and the computer program includes a program code for executing the custom interface authentication method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 1009, and / or installed from the removable medium 1011. When the computer program is executed by the processor 1001, the above-mentioned functions defined in the system of the embodiment of the present application are executed. According to an embodiment of the present application, the system, equipment, device, module and / or unit described above can be implemented by a computer program module.

[0120] Embodiments of the present application also provide a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments, or may exist independently without being incorporated into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the steps of the custom interface authentication method according to the embodiments of the present application.

[0121] According to an embodiment of the present application, the computer-readable storage medium may be a non-volatile computer-readable storage medium, for example, it may include but is not limited to: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In an embodiment of the present application, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, apparatus, or device. For example, according to an embodiment of the present application, the computer-readable storage medium may include one or more memories other than the ROM 1002 and / or RAM 1003 described above.

[0122] It should be noted that the functional modules in the various embodiments of the present application can be integrated into a processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The above-mentioned integrated modules can be implemented in the form of hardware or in the form of software functional modules. If the integrated modules are implemented in the form of software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product.

[0123] The flowcharts and / or block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flowchart and / or block diagram can represent a module, a program segment or a part of code, and the part of the above-mentioned module, program segment or code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. It should also be noted that each box in the block diagram or flowchart, and the combination of the boxes in the block diagram or flowchart, can be implemented by a special hardware-based system that performs the specified function or operation, or can be implemented by a combination of special hardware and computer instructions.

[0124] Those skilled in the art will appreciate that the features described in the various embodiments and / or claims of this application may be combined and / or coupled in various ways, even if such combinations and / or couplings are not explicitly described in this application. In particular, without departing from the spirit and teachings of this application, the technical features described in the various embodiments and / or claims of this application may be combined and / or coupled in various ways, and all such combinations and / or couplings fall within the scope of this application.

[0125] Although the present application has been shown and described with reference to certain exemplary embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made to the present application without departing from the spirit and scope of the present application as defined by the appended claims and their equivalents. Therefore, the scope of the present application should not be limited to the above-described embodiments, but should be determined not only by the appended claims but also by the equivalents of the appended claims.

Claims

1. A custom interface authentication method for an open source system framework layer, characterized in that: include: Creating a custom service in the open source system framework layer, wherein the custom service provides at least one custom interface; Establish an encrypted authentication whitelist file; Integrate an authentication trigger mechanism in the custom interface to execute the authentication process when an external application calls the custom interface; If the authentication is successful, the functional logic of the custom interface is executed.

2. The custom interface authentication method according to claim 1, wherein: The authentication whitelist file for establishing encrypted storage includes: Receive the package name of the application that needs to be authorized and the corresponding signature fingerprint information provided by the caller; the package name of the application can be determined in advance, and the signature fingerprint information can be obtained when the system is signed; The authentication whitelist file is encrypted and stored in a specified path of the system partition.

3. The user-defined interface authentication method according to claim 1, wherein: The authentication process includes: Get the package name of the calling application; Verify whether the package name of the caller application exists in the authentication whitelist file. If not, the authentication fails. If so, further obtain the signature fingerprint information of the caller application and compare it with the fingerprint recorded in the authentication whitelist file; If the fingerprints are consistent, the authentication is successful and the functional logic of the custom interface is executed; if the fingerprints are inconsistent, the authentication fails.

4. The user-defined interface authentication method according to claim 3, wherein: Verifying whether the package name of the caller application exists in the authentication whitelist file includes: Obtain the full package name of the calling application through the open source system package management interface; Verify that the complete package name is fully matched with the records in the authentication whitelist file; If there is no match, an authentication failure response code is generated and subsequent operations are terminated.

5. The user-defined interface authentication method according to claim 3, wherein: The signature fingerprint information of the caller application is compared with the fingerprint recorded in the authentication whitelist file, including: Obtain the digital certificate data of the caller application through the open source system package management interface; Performing an encryption algorithm on the digital certificate data to generate a current signature fingerprint; Perform fingerprint byte-level comparison. If the matching threshold reaches the preset ratio, the fingerprint comparison verification is considered successful.

6. The user-defined interface authentication method according to claim 1, wherein: It also includes a whitelist file update mechanism; The whitelist file update mechanism includes an offline update method and / or an online update method; Offline update mode: receive the encrypted authentication whitelist file update package through the physical interface, verify the device digital signature and replace the old file; Online update mode: download the encrypted authentication whitelist file update package from the authorization server, verify the legitimacy of the digital certificate chain and decrypt it before it takes effect.

7. The user-defined interface authentication method according to claim 1, wherein: It also includes authentication optimization strategies; The authentication optimization strategy includes: Establish a memory cache table to cache the package name and signature fingerprint information of successfully authenticated applications; Repeated call requests within the cache validity period directly return the authentication success status.

8. The user-defined interface authentication method according to claim 1, wherein: It also includes exception handling procedures; The exception handling process includes: When the number of consecutive authentication failures reaches the preset threshold, the system security policy is triggered to block the calling process; Generates encrypted audit logs and stores them in a secure storage partition. The encrypted audit logs include timestamps, package names, and abnormal fingerprint fragments.

9. An electronic device, characterized in that: It includes at least one processing unit and at least one storage unit, wherein the storage unit stores a computer program, and when the computer program is executed by the processing unit, the processing unit is able to perform the steps of the custom interface authentication method described in any one of claims 1 to 8.

10. A storage medium, characterized in that: It stores a computer program executable by an access authentication device. When the computer program runs on the access authentication device, the access authentication device is enabled to execute the steps of the custom interface authentication method according to any one of claims 1 to 8.

Images