An application installation method, electronic equipment, chip system and readable storage medium

Abstract

This application provides an application installation method, an electronic device, a chip system, and a readable storage medium. The method includes: obtaining an installation package of a target application, target data, and a first signature corresponding to the target data. The first signature is obtained by signing the target data after the installation package passes security testing. The first signature is verified based on a target deployment certificate, which proves that a trusted object has the authority to deploy applications on devices managed by the trusted object. The target data includes an identifier of the device managed by the trusted object. If the first signature verification passes and a first terminal device belongs to a device managed by the trusted object, the target application is installed based on the installation package. Thus, the installation package installed on the first terminal device passes security testing, reducing the risk of installing the target application and improving the user experience.

Description

Technical Field

[0001] This application relates to the field of terminals, and more particularly to an application installation method, electronic device, chip system, and readable storage medium. Background Technology

[0002] Currently, distributing applications (apps) through app stores is a mature and secure technology. However, this distribution method is not suitable for all scenarios, such as when an application is being distributed during its development process. In such scenarios, the application is in an intermediate stage and needs to be distributed through methods other than app stores.

[0003] In related technologies, for non-app market distribution methods, developers typically develop the target application and then sign the application's installation package using the private key corresponding to their developer certificate (i.e., the developer's private key), obtaining a developer signature. The developer signature and the installation package are then sent to a server. When a user wants to install the target application via their terminal device, they can retrieve the application's installation package and the developer signature from the server. The terminal device then verifies the developer signature; if verification is successful, the target application is installed based on the installation package.

[0004] However, if an attacker illegally obtains the developer's certificate and its corresponding private key, they can sign the installation package of a malicious application, allowing the terminal device to install the malicious application if the signature verification is successful. This would expose the terminal device to significant security risks. Summary of the Invention

[0005] This application provides an application installation method that reduces the risk of installing target applications and improves user experience.

[0006] Firstly, an application installation method is provided, comprising: obtaining an installation package of a target application, target data, and a first signature corresponding to the target data, wherein the first signature is obtained by signing the target data after the installation package passes security testing; verifying the first signature based on a target deployment certificate, the target deployment certificate being used to prove that a trusted object has the authority to deploy applications on devices managed by the trusted object; the target data including the identifier of the devices managed by the trusted object; and, if the first signature verification passes and the first terminal device belongs to a device managed by the trusted object, installing the target application based on the installation package. Deploying an application includes at least one of installing an application, configuring an application, and running an application.

[0007] The method can be executed by the first terminal device, or applied to a module (such as a processor, chip, or chip system) in the first terminal device, or implemented by a logic module or software that can implement all or part of the functions of the first terminal device.

[0008] In the above solution, the installation package used when the target application is installed on the first terminal device has passed security testing. Installing the target application based on the installation package can prevent the implantation of malicious code, ensure the normal operation of the target application and data security, and improve the overall security and reliability of the system.

[0009] It should be understood that the first signature can be obtained by signing the target data using the private key of a trusted object, assuming the installation package passes security checks. The first signature can be understood as the signature of the trusted object; the target deployment certificate carries the public key of the trusted object corresponding to its private key. The target application is an application authorized to be installed on devices managed by the trusted object.

[0010] In one possible implementation, the trusted object is either a first object or a second object, where the first object can be a target individual (e.g., XX person) and the second object can be a target enterprise (e.g., MM enterprise).

[0011] In one possible implementation, the target data also includes information for identifying the installation package, and the target data is used to authorize the installation of the target application on devices managed by trusted objects.

[0012] Based on the above scheme, by binding the information used to identify the installation package with the identifier of the device managed by the trusted object, the installation of the target application is authorized on the device managed by the trusted object. This ensures that the target application can only be installed and run on the device managed by the trusted object, thereby improving the security of the target application and preventing its abuse.

[0013] In one possible implementation, the information used to identify the installation package can also prevent the installation package from being tampered with.

[0014] In one possible implementation, the information used to identify the installation package could be a first hash value.

[0015] In one possible implementation, if the first signature verification passes, it indicates that the integrity verification of the target data has passed, meaning that the target data is tamper-proof and trustworthy. Subsequently, the identifier of the device managed by the trusted object in the target data can be matched with the identifier of the first terminal device. If the identifier of the first terminal device is present in the identifiers of the devices managed by the trusted object, it is determined that the first terminal device belongs to the device managed by the trusted object.

[0016] The target deployment certificate is the end certificate in the certificate chain. The identifier of the device managed by the trusted object is used to uniquely identify the device managed by the trusted object. The target deployment certificate includes the identifier of the device managed by the trusted object.

[0017] In one possible implementation, the identifier of the device managed by the trusted object can consist of two parts: the identifier of the trusted object and the device identifier, such as the device serial number (SN).

[0018] In one possible implementation, the target deployment certificate is obtained by: receiving a certificate chain; and retrieving the target deployment certificate from the certificate chain.

[0019] In one possible implementation, a certificate chain is received, which includes a target deployment certificate and at least one of the following certificates: a deployment certificate, an enterprise application marketplace deployment certificate, and a personal deployment certificate.

[0020] The root certificate can issue deployment certificates, which can then issue enterprise app market deployment certificates and / or personal deployment certificates. Personal deployment certificates issue a first deployment certificate, which is the target personal deployment certificate, such as "XX Personal Deployment Certificate." Enterprise app market deployment certificates issue a second deployment certificate, which is the target enterprise deployment certificate, such as "MM Enterprise Deployment Certificate."

[0021] In one possible implementation, after determining the validity of the certificate chain based on the root public key (i.e., the certificate chain is trustworthy or has not been tampered with), the public key (i.e., the public key of the trusted object) is extracted from the target deployment certificate. The first signature is then verified using the public key of the trusted object.

[0022] In one possible implementation, the trusted object is a first object, and the target deployment certificate is a first deployment certificate. The first deployment certificate is used to prove that the first object has the authority to deploy applications on the devices managed by the first object, and to obtain the installation package of the target application, target data, and the first signature corresponding to the target data. This includes: receiving the installation package from the second terminal device; and, if the installation package passes the security test, obtaining the target data and signing the target data based on the private key (i.e., the private key of the trusted object) of the first deployment certificate through the deployment tool of the first terminal device to obtain the first signature.

[0023] For example, the first object is the target individual.

[0024] The second terminal device can be the device used by the developer. Security checks can be performed by scanning the installation package using security scanning tools.

[0025] Based on the above scheme, when the trusted object is the first object, the first terminal device can perform security checks on the received installation package. If the security check is passed, the first terminal device's deployment tool uses the first object's private key to sign the target data to obtain the first signature. Finally, before installing the target application, the terminal device's installation tool can verify the first signature based on the first deployment certificate. If the first signature verification is successful and the first terminal device belongs to the device managed by the first object, the target application can be installed based on the installation package. This prevents the injection of malicious code, ensures the normal operation of the target application and data security, and improves the overall security and reliability of the system.

[0026] The target application's installation package is an unmodified installation package from the second terminal device.

[0027] In one possible implementation, the target data includes a first hash value of the installation package and an identifier of the device managed by the first object. The target data is used to authorize the installation of the target application on the device managed by the first object.

[0028] In one possible implementation, a second signature corresponding to the installation package is received from a second terminal device; if the installation package is determined to be untampered based on the second signature, a security check is performed on the installation package.

[0029] For example, the second signature can be obtained by the second terminal device signing the second hash value of the installation package using the developer's private key. The second hash value of the installation package is obtained by the second terminal device after hashing the installation package. The first terminal device can verify the developer certificate using the root public key. If the developer certificate is valid, the first terminal device can extract the developer's public key from the developer certificate. Subsequently, the second signature is verified using the developer's public key. If the verification is successful, it indicates that the installation package received from the second terminal device has not been tampered with.

[0030] In one possible implementation, assuming the installation package has not been tampered with and has passed security checks, the target data is signed using the private key of the first object to obtain the first signature.

[0031] It should be noted that verifying whether the installation package has been tampered with and performing security checks on the installation package using deployment tools can be done simultaneously, or the installation package can be verified for tampering first, and then the security checks can be performed on the installation package if it has not been tampered with. Alternatively, the installation package can be security checked first, and then verified for tampering if the installation package passes the security checks.

[0032] In one possible implementation, the first deployment certificate is obtained by: sending a first acquisition request to a first server, the first acquisition request being used to obtain the first deployment certificate; and receiving the first deployment certificate from the first server. The first acquisition request carries the identifier of the device managed by the first object and the public key of the first object. The first server is a server that deploys the application marketplace. The identifier of the device managed by the first object is used to uniquely identify the device managed by the first object, and the identifier of the device managed by the first object can consist of two parts: the identifier of the first object and the device serial number (SN). The number of device SNs can be at least one. The first object can be a target individual, such as XX individuals.

[0033] In one possible implementation, the trusted object is a first object, and the target data includes the identifier of the device managed by the first object and a first hash value of the installation package. This target data is used to authorize the installation of the target application on the device managed by the first object. The first hash value also prevents the installation package from being tampered with during transmission from the deployment tool to the installation tool.

[0034] In one possible implementation, the trusted object is the first object, and the certificate chain includes a deployment certificate, a personal deployment certificate, and a target personal deployment certificate, such as XX Personal Deployment Certificate. The certificate chain is sent from the first server to the first terminal device.

[0035] In one possible implementation, the trusted object is a second object, and the target deployment certificate is a second deployment certificate. The second deployment certificate is used to prove that the second object has the authority to deploy applications on the devices managed by the second object, and to obtain the installation package, target data, and first signature corresponding to the target application, including receiving the installation package, target data, and first signature from the second server.

[0036] Based on the above scheme, when the trusted object is the second object, the first terminal device can receive the installation package, target data, and first signature from the second server (such as an enterprise server). Before installing the target application, if the first terminal device is a device managed by the second object, the target application is installed based on the installation package that has passed security checks, thereby ensuring the reliability and security of the installed target application.

[0037] In one possible implementation, the second object is the target enterprise, and the certificate chain includes a deployment certificate, an enterprise application marketplace deployment certificate, and the target enterprise deployment certificate. The certificate chain is sent from the first server to the second server, and then from the second server to the first terminal device.

[0038] Secondly, an application installation method is provided, comprising: receiving an installation package of a target application from a second terminal device; if the installation package passes a security check, obtaining target data and signing the target data based on the private key corresponding to the second deployment certificate (i.e., the private key of the second object) to obtain a first signature, wherein the second deployment certificate is used to prove that the second object has the authority to deploy the application on the device managed by the second object, and the target data includes the identifier of the device managed by the second object; and sending the installation package, the target data, and the first signature to a first terminal device.

[0039] This method can be executed by a second server, or by a module within the second server (such as a processor, chip, or chip system), or by a logic module or software capable of implementing all or part of the functions of the second server. The second server could be, for example, an enterprise server.

[0040] Based on the above scheme, if the installation package passes the security test, the target data can be signed using the private key of the second object to obtain the first signature, so that the devices managed by the second object can subsequently install the target application, thereby preventing malicious applications from being installed, reducing the risk of application installation, and improving the overall security and reliability of the system.

[0041] In one possible implementation, the target data also includes information for identifying the installation package, and the target data is used to authorize the installation of the target application on the device managed by the second object.

[0042] In one possible implementation, the information is a first hash value of the installation package, which also serves to prevent the installation package from being tampered with during transmission from the second server to the first terminal device.

[0043] In one possible implementation, the second deployment certificate is obtained by: sending a second acquisition request to a first server to obtain the second deployment certificate; and receiving a first deployment certificate from the first server. The first server is a server that deploys the application marketplace. The second acquisition request carries the identifier of the device managed by the second object and the public key of the second object. The identifier of the device managed by the second object is used to uniquely identify the device managed by the second object, and the identifier of the device managed by the second object can consist of two parts: the identifier of the second object and the device serial number (SN).

[0044] In one possible implementation, the second deployment certificate includes the identifier of the device managed by the second object.

[0045] In one possible implementation, a second signature corresponding to the installation package is received; if it is determined based on the second signature that the installation package has not been tampered with, a security check is performed on the installation package.

[0046] For example, the second signature can be obtained by the second terminal device signing the second hash value of the installation package using the developer's private key. The second hash value of the installation package is obtained by the second terminal device after hashing the installation package. The second server can verify the developer certificate using the root public key. If the developer certificate is valid, it can extract the developer's public key from the developer certificate. Subsequently, it verifies the second signature using the developer's public key. If the verification is successful, it indicates that the installation package received from the second terminal device has not been tampered with.

[0047] In one possible implementation, assuming the installation package has not been tampered with and has passed security checks, the second server uses the private key of the second object to sign the target data to obtain the first signature.

[0048] The second server can verify whether the installation package has been tampered with and perform security checks on the installation package simultaneously. Alternatively, it can verify the installation package's tampering status first, and then perform security checks if the installation package has not been tampered with. Of course, it can also perform security checks on the installation package first, and then verify whether the installation package has been tampered with if the security checks are passed.

[0049] In one possible implementation, the second object is the target enterprise, which sends a certificate chain to the first terminal device. This certificate chain includes a deployment certificate, an enterprise application market deployment certificate, and a target enterprise deployment certificate.

[0050] Thirdly, an application installation method is provided, the method comprising: receiving an acquisition request, the acquisition request being used to acquire a target deployment certificate; and based on the acquisition request, sending the target deployment certificate, the target deployment certificate being used to prove that a trusted object has the authority to deploy applications on devices managed by the trusted object, the target deployment certificate including the identifier of the devices managed by the trusted object.

[0051] The method can be executed by the first server, or applied to a module (such as a processor, chip, or chip system) in the first server, or implemented by a logic module or software that can implement all or part of the functions of the first server.

[0052] In one possible implementation, the trusted object is either a first object or a second object. The first object is the target individual, such as individual XX. The second object is the target company, such as company MM.

[0053] Fourthly, embodiments of this application provide an electronic device, which includes a processor and a memory. The memory is used to store a computer program, and the processor is used to call and run the computer program from the memory, causing the electronic device to perform the method in any of the above aspects or any possible implementations of any of the above aspects.

[0054] Fifthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to perform the method in any of the above aspects or any possible implementations of any of the above aspects.

[0055] Sixthly, embodiments of this application provide a computer program product, which includes computer program code. When the computer program code is run by an electronic device, the electronic device performs the method in any of the above aspects or any possible implementation of any of the above aspects.

[0056] In a seventh aspect, embodiments of this application provide a chip system, which includes a processing circuit and a storage medium storing computer program instructions; the computer program instructions are executed by the processing circuit using any of the above aspects or any possible implementations of any of the above aspects.

[0057] Optionally, the processing circuitry in the above-mentioned chip system can be replaced by a processor, and the storage medium can be replaced by a memory. Optionally, the chip system may also include a communication interface for enabling communication between the chip system and external devices.

[0058] The beneficial effects of the technical solutions in the second to seventh aspects of this application can be referred to the beneficial effects of the technical solutions in the first aspect, and will not be repeated here. Attached Figure Description

[0059] Figure 1 This is a schematic diagram of the structure of an electronic device 100 provided in an embodiment of this application;

[0060] Figure 2 This is a software structure block diagram of the electronic device 100 according to an embodiment of this application;

[0061] Figure 3 This is a flowchart illustrating an application installation method 300 provided in an embodiment of this application;

[0062] Figure 4 This is a schematic diagram of a certificate issuance chain provided in an embodiment of this application;

[0063] Figure 5 This is a schematic diagram of the structure of the MM enterprise deployment certificate provided in the embodiments of this application;

[0064] Figure 6 This is a schematic diagram of the two-signature process of the target application in an application installation method provided in an embodiment of this application;

[0065] Figure 7 This is a flowchart illustrating another application installation method 700 provided in an embodiment of this application;

[0066] Figure 8 This is a schematic diagram of another certificate issuance chain provided in an embodiment of this application;

[0067] Figure 9 This is a schematic diagram of the structure of the XX personal deployment certificate provided in the embodiments of this application;

[0068] Figure 10 This is a schematic diagram of the two-signature process of the target application in another application installation method provided in this application embodiment;

[0069] Figure 11 This is a flowchart illustrating an application installation method 1100 provided in an embodiment of this application;

[0070] Figure 12 This is a flowchart illustrating an application installation method 1200 provided in an embodiment of this application;

[0071] Figure 13 This is a flowchart illustrating an application installation method 1300 provided in an embodiment of this application;

[0072] Figure 14 This is a schematic diagram of the installation function configuration interface of the first terminal device in an application installation method provided in this application embodiment;

[0073] Figure 15 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0074] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0075] In the description of the embodiments of this application, unless otherwise stated, " / " means "or"; for example, A / B can mean A or B; "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist; for example, A and / or B can mean: A exists alone, A and B exist simultaneously, or B exists alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more.

[0076] Hereinafter, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first," "second," or "third" may explicitly or implicitly include one or more of that feature.

[0077] This application provides an electronic device for executing the application installation method provided in this application. In some embodiments of this application, the electronic device may be a mobile phone, tablet computer, wearable device, in-vehicle device, augmented reality (AR) / virtual reality (VR) device, laptop computer, ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), etc., or may be other devices or apparatuses capable of installing applications. This application does not limit the specific type of electronic device.

[0078] For example, Figure 1 This is a schematic diagram of the structure of an electronic device 100 provided in an embodiment of this application. The electronic device 100 may include a processor 110, a memory 120, a communication module 130, and a display screen 140, etc.

[0079] The processor 110 may include one or more processing units, and the memory 120 is used to store program code and data. In this embodiment, the processor 110 can execute the program code stored in the memory 120 to control and manage the operation of the electronic device 100.

[0080] The communication module 130 can be used for communication between various internal modules of the electronic device 100, or for communication between the electronic device 100 and other external devices. For example, if the electronic device 100 communicates with other devices via a wired connection, the communication module 130 may include an interface, such as a USB interface. The USB interface can be an interface conforming to the USB standard specification, specifically a Mini USB interface, a Micro USB interface, a USB Type-C interface, etc. The USB interface can be used to connect a charger to charge the electronic device 100, or to transfer data between the electronic device 100 and peripheral devices. It can also be used to connect headphones for audio playback.

[0081] Alternatively, the communication module 130 may include one or more of the following: audio devices, radio frequency circuits, Bluetooth chips, wireless fidelity (Wi-Fi) chips, near-field communication (NFC) modules, etc., which can enable the electronic device 100 to interact with other devices in a variety of different ways.

[0082] The display screen 140 can display text, images, or videos from the human-computer interaction interface. In some embodiments, the display screen 140 can be a flexible screen, which can be stretched or unfolded to form a larger display screen, or rolled or folded to form a smaller display screen.

[0083] It should be understood that, in addition to Figure 1 In addition to the various components or modules listed, the embodiments of this application do not specifically limit the structure of the electronic device 100. In other embodiments of this application, the electronic device 100 may also include more or fewer components than those shown in the figures, or combine some components, or split some components, or have different component arrangements. The components shown in the figures may be implemented in hardware, software, or a combination of software and hardware.

[0084] The software system of electronic device 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application embodiment uses a layered Android system as an example to illustrate the software structure of electronic device 100.

[0085] Figure 2 This is a software structure block diagram of the electronic device 100 according to an embodiment of this application.

[0086] It should be understood that a layered architecture can divide software into several layers, each with a clear role and division of labor; the layers can communicate with each other through software interfaces.

[0087] like Figure 2 As shown, the Android system can be divided into four layers: from top to bottom, the application layer, the application framework layer, the Android runtime and system libraries, and the kernel layer. The application layer can include a series of application packages.

[0088] like Figure 2 As shown, the application package may include applications such as camera, gallery, map, navigation, WLAN, Bluetooth, music, SMS, and communication applications.

[0089] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0090] like Figure 2 As shown, the application framework layer may include a window manager, content provider, view system, phone manager, resource manager, notification manager, etc.

[0091] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0092] like Figure 2 As shown, the application framework layer may include a window manager, content provider, view system, phone manager, resource manager, notification manager, etc.

[0093] The window manager is used to manage windowed applications. It can retrieve screen size, determine the presence of a status bar, lock the screen, and capture screenshots, among other things.

[0094] Content providers store and retrieve data, making that data accessible to applications. This data can include videos, images, audio, phone calls made and received, browsing history and bookmarks, phone books, and more.

[0095] A view system includes visual controls, such as controls for displaying text and controls for displaying images. View systems can be used to build applications. A display interface can consist of one or more views.

[0096] The phone manager is used to provide communication functions for electronic device 100. For example, it manages call status (including connection and disconnection).

[0097] The file explorer provides applications with various resources, such as localized strings, icons, images, layout files, video files, and more.

[0098] The notification manager allows applications to display notification information in the status bar. It can be used to convey informational messages and can disappear automatically after a short time without user interaction.

[0099] The Android runtime consists of core libraries and a virtual machine. The Android runtime is responsible for scheduling and managing the Android system.

[0100] The core library consists of two parts: one part is the functionalities that need to be called by the Java language, and the other part is the Android core library.

[0101] The application layer and application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0102] The system library can include multiple functional modules, such as: surface manager, media libraries, 3D graphics processing libraries (e.g., OpenGL ES for embedded systems) and 2D graphics engines (e.g., Skia graphics library (SGL)).

[0103] The Surface Manager is used to manage the display subsystem and provides the blending of 2D and 3D layers for multiple applications.

[0104] The media library supports playback and recording of various audio and video formats, as well as still image files. It supports multiple audio and video encoding formats, such as MPEG4, H.264, Moving Picture Experts Group Audio Layer III (MP3), Advanced Audio Coding (AAC), Adaptive Multi-rate (AMR), Joint Photographic Experts Group (JPG), and Portable Network Graphics (PNG).

[0105] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

[0106] A 2D graphics engine is a graphics engine for 2D drawing.

[0107] The kernel layer is the layer between hardware and software. The kernel layer contains at least the display driver, camera driver, audio driver, and sensor driver.

[0108] The application installation method provided in this application embodiment will be specifically described below with reference to the accompanying drawings and application scenarios. Exemplarily, the first terminal device, second terminal device, first server, or second server in the following embodiments can be... Figure 1 and Figure 2 The electronic device shown.

[0109] To facilitate understanding of the technical solutions of this application, the following introduces the technical terms and related background involved in this application:

[0110] App stores are platforms that offer a variety of applications, allowing users to download and install the applications they need. App stores can review submitted application packages, checking for malicious code, viruses, or prohibited content. Only applications that pass the review can be published on the app store.

[0111] Enterprise app marketplace: A platform operated by an enterprise to provide application downloads and management services to its internal employees. It can also be referred to as the enterprise's internal app marketplace.

[0112] Digital signature: A cryptographic technique used to verify the authenticity and integrity of information and ensure that the information has not been tampered with during transmission. Digital signature can also be simply referred to as a signature.

[0113] Developer Certificate: A certificate issued by an app store to qualified enterprise or individual developers.

[0114] Application, or simply application.

[0115] Currently, distributing applications through app stores is not suitable for all scenarios. For example, applications distributed during development are in an intermediate state and not suitable for app store distribution. Additionally, in enterprise office scenarios, terminal devices often need to install customized applications purchased by the enterprise; these applications, due to their involvement in specific business operations, are also unsuitable for distribution through app stores. For these scenarios, non-app store distribution methods are needed. However, with non-app store distribution, the application installation package has not been reviewed by the app store, and its security and purity rely entirely on the developer. After obtaining the installation package through non-app store distribution, the terminal device verifies the developer's signature. If the developer's signature verification is successful, the application will be installed based on the installation package. In this process, the terminal device is in a state of complete trust in the developer, which exposes it to significant security risks.

[0116] For example, an attacker can illegally purchase a developer certificate with in-house (i.e., enterprise developer) qualifications and its corresponding private key. They then use this private key to sign the installation package of a malicious application, obtaining a developer signature, and send the installation package and developer signature to a server; the malicious application may be an application containing malicious code. The terminal device can download the malicious application's installation package and developer signature from the server and verify the developer signature. If the developer signature verification is successful, the terminal device installs the malicious application based on the installation package. In this way, the malicious application is successfully installed on the terminal device, potentially threatening the secure operation of the terminal device and degrading the user experience.

[0117] Based on this, this application provides an application installation method. The first terminal device is a device managed by a trusted object, and the installation package of the target application installed on the first terminal device has passed security testing. Installing the target application based on this installation package can reduce the possibility of malicious application installation, lower the installation risk, and improve the overall user experience. The following provides a detailed explanation of this application installation method through multiple embodiments.

[0118] Figure 3 This is a flowchart illustrating an application installation method 300 provided in an embodiment of this application. Figure 3 As shown, the application installation method 300 is applied to an application distribution system, which includes terminal device A1, terminal device A2, server B1, and server B2. Terminal device A1 is, for example, a device used by a developer, and terminal device A2 is a device used to install the target application. Server B1 may be a server with an application marketplace deployed, and server B2 may be a server with an internal application marketplace deployed by MM Enterprise. Server B1 establishes communication connections with both terminal device A1 and server B2, and server B2 establishes communication connections with both terminal device A1 and terminal device A2. The application installation method 300 includes steps S301 to S310. This method 300 does not... Figure 3 The specific order is a limitation. It should be understood that in other embodiments, the order of some steps in method 300 can be interchanged according to actual needs, or some steps can be omitted or deleted. The following is a detailed explanation of each step of method 300.

[0119] S301 and terminal device A1 use the developer's private key to sign the hash value of the target application's installation package to obtain the developer's signature.

[0120] In one possible implementation, the installation package of the target application can be an installation package in an intermediate state during the development of the target application. Alternatively, the installation package of the target application can be an installation package of a custom application purchased by the enterprise. The hash value of the installation package of the target application is obtained by the terminal device A1 after hashing the installation package of the target application.

[0121] The developer certificate can be obtained in advance by the developer from the application market on server B1 via terminal device A1. The developer certificate contains the developer's public key, which corresponds to the developer's private key.

[0122] For example, terminal device A1 can send a processing request to server B1 to apply for a developer certificate. Server B1 can respond to the processing request by generating a developer certificate and sending it to terminal device A1. The processing request carries the developer's identity information and public key; the developer's identity information could be, for example, a developer account. The developer account could be an account registered by the developer through terminal device A1 for accessing the app store. The developer certificate includes the developer account, the developer's public key, and a certificate signature, which is the app store's signature.

[0123] S302, Terminal device A1 sends a developer signature, an installation package, a hash value of the installation package, and a profile file of the target application to server B2. Correspondingly, server B2 receives the developer signature, the installation package, the hash value of the installation package, and the profile file of the target application.

[0124] The Profile file can be a file requested by the terminal device A1 from the app store to describe the target application. This Profile file includes the developer certificate, the target application's identification number (ID), other information about the target application, and a Profile file signature. The Profile file signature is a signature from the app store, used to prove that the target application's identity is recognized by the app store.

[0125] S303 and server B2 verify the developer's signature and, if the verification is successful, determine whether the installation package has been tampered with based on the hash value of the installation package.

[0126] In one possible implementation, the developer certificate can be verified using the root public key. If verification is successful, it indicates that the developer certificate has not been tampered with (i.e., the developer certificate is legitimate or trustworthy). The developer certificate can be sent from terminal device A1 to server B2. Next, server B2 can extract the developer's public key from the developer certificate and use it to verify the developer's signature. If verification is successful, server B2 can hash the installation package to obtain a first hash value and compare the hash value of the received installation package with this first hash value. If the hash value of the received installation package matches the first hash value, it indicates that the installation package has not been tampered with.

[0127] S304 and server B2 perform security checks on the installation package if the installation package has not been tampered with.

[0128] In one possible implementation, the installation package is subjected to security checks using a security scanning tool. These checks may include detecting the presence of malicious code or viruses within the installation package.

[0129] S305. If the security test is passed, server B2 uses MM Enterprise's private key to sign the first target data to obtain MM Enterprise's internal application market signature. The first target data contains the hash value of the installation package, MM Enterprise's ID, and a list of device serial numbers (SNs). The list of device SNs includes at least one device SN.

[0130] The MM enterprise deployment certificate carries the MM enterprise's public key, corresponding to the MM enterprise's private key. This certificate is used to verify the signatures of MM enterprise's internal application marketplace. The MM enterprise's private key can also be referred to as the private key corresponding to the MM enterprise deployment certificate.

[0131] MM Enterprise Deployment Certificates can be issued by the app store to MM enterprises. MM Enterprise Deployment Certificates are also known as MM Enterprise Deployment Certificates. The first target data is used to authorize the installation of the target application on devices managed by the MM enterprise. Alternatively, the first target data can be understood as authorizing the target application to be installed on devices managed by the MM enterprise.

[0132] Figure 4 This is a schematic diagram of a certificate issuance chain provided in an embodiment of this application. In the certificate issuance system, the root certificate is the highest-level certificate, and it has the authority to issue other certificates. Figure 4As shown, the root certificate first issues developer certificates and deployment certificates. The deployment certificates then issue app store deployment certificates and enterprise app store deployment certificates. The enterprise app store deployment certificate, in turn, issues MM enterprise deployment certificates. The app store can manage developer certificates, deployment certificates, app store deployment certificates, enterprise app store deployment certificates, and MM enterprise deployment certificates.

[0133] In one possible implementation, server B2 can send a request to server B1 to obtain the MM enterprise deployment certificate. This request includes the MM enterprise's ID, device serial number list, and public key. Server B1, in response to the request, generates the MM enterprise deployment certificate through the application marketplace and sends it to server B2. The MM enterprise deployment certificate serves to prove that the MM enterprise has the authority to deploy applications on devices managed by the MM enterprise.

[0134] For example, Figure 5 This is a schematic diagram illustrating the structure of the MM enterprise deployment certificate provided in an embodiment of this application. Figure 5 As shown, the MM enterprise deployment certificate includes the MM enterprise's ID, SN list, public key, and certificate signature. This certificate signature is the application marketplace's signature. The MM enterprise deployment certificate is in X.509 format.

[0135] Figure 6 This diagram illustrates the two-stage signing process of the target application in an application installation method provided in this application embodiment. Figure 6As shown, the developer can use terminal device A1 to sign the hash value of the target application's installation package using their private key (i.e., the first signature), obtaining the developer signature, also known as the installation package developer signature. Subsequently, the developer uses terminal device A1 to generate a compressed package based on the developer signature, the installation package, the installation package's hash value, and the profile file, and sends this compressed package to server B2. Server B2 can decompress the compressed package to obtain the developer signature, the installation package, the installation package's hash value, and the profile file. Next, server B2 verifies the developer signature using MM Enterprise's internal application marketplace based on the developer certificate. If the verification is successful, it determines whether the installation package has been tampered with based on the installation package's hash value. If the installation package has not been tampered with, a security check is performed on the installation package. If the security check passes, the developer uses MM Enterprise's private key to sign the installation package's hash value, MM Enterprise's ID, and the device SN list (i.e., the second signature), obtaining MM Enterprise's internal application marketplace signature; this MM Enterprise signature can be simply referred to as the MM Enterprise signature. In this way, by using MM's internal application marketplace, the installation packages are security tested and signed, enabling devices managed by MM to install security-tested packages, thus reducing the security risks faced by the target applications.

[0136] S306, Server B2 sends the installation package, Profile file, and first target data, along with the MM company's internal application market signature, to terminal device A2. Correspondingly, terminal device A2 receives the installation package, the first target data, and the MM company's internal application market signature.

[0137] In one possible implementation, the installation package, the first target data, and the MM enterprise's internal application market signature can be sent proactively by server B2. Alternatively, server B2 can send these based on a request from terminal device A2 to obtain the installation package of the target application.

[0138] For example, in response to a user's download operation, terminal device A2 may send a request to server B2 to obtain the installation package of a target application. Server B2 receives the request, which carries the identifier of the target application, used to uniquely identify the target application. In response to the request, server B2, based on the identifier of the target application, sends the installation package, first target data, and the internal application market signature of MM Enterprise to terminal device A2.

[0139] S307 and terminal device A2 verify the signature of MM Enterprise's internal application marketplace based on the certificate chain and root public key. The certificate chain includes MM Enterprise's deployment certificate.

[0140] For example, such as Figure 4 As shown, the certificate chain includes the deployment certificate, the enterprise application marketplace deployment certificate, and the MM enterprise deployment certificate. Terminal device A2 can use the root public key to verify the certificate chain. First, the deployment certificate is verified using the root public key. If the deployment certificate verification is successful, the deployment public key is extracted from it. Next, the enterprise application marketplace deployment certificate is verified using the deployment public key. If the enterprise application marketplace deployment certificate verification is successful, the enterprise application marketplace deployment public key is extracted from it, and then used to verify the MM enterprise deployment certificate. If the MM enterprise deployment certificate verification is successful, the MM enterprise's public key is extracted from it. Finally, the MM enterprise's public key is used to verify the MM enterprise's internal application marketplace signature.

[0141] S308 and terminal device A2, after passing the signature verification in MM Enterprise's internal application market, perform hash processing on the received installation package to obtain a new hash value.

[0142] This new hash value can be represented as the second hash value.

[0143] S309. If the terminal device A2 passes the signature verification in the internal application market of MM Enterprise, determine whether the terminal device A2 belongs to the device managed by MM Enterprise based on the ID and device SN list of MM Enterprise.

[0144] The MM company ID is used to uniquely identify the MM company. The MM company ID and the device SN in the device SN list are used to uniquely identify the devices managed by the MM company.

[0145] For example, the ID of the enterprise to which terminal device A2 belongs can be matched with the ID of MM enterprise, and the device SN of terminal device A2 can be matched with multiple device SNs in the device SN list. If the ID of the enterprise to which terminal device A2 belongs matches (i.e., is consistent) with the ID of MM enterprise, and there is a device SN in the multiple device SNs in the SN list that matches (i.e. is consistent) with the device SN of terminal device A2, it is determined that terminal device A2 belongs to the device managed by MM enterprise.

[0146] S310. If the new hash value is consistent with the hash value in the first target data, and the terminal device A2 is a device managed by MM Enterprise, install the target application based on the received installation package, and output the detailed information of the installed target application based on the Profile file.

[0147] This application provides an application installation method. When the terminal device A2 installs the target application, the installation package used is security tested and confirmed by the private key signature of MM Enterprise. Installing the target application based on this installation package can reduce the possibility of malicious application installation, reduce installation risk, and improve the overall user experience.

[0148] Figure 7 This is a flowchart illustrating another application installation method 700 provided in an embodiment of this application. Figure 7 As shown, the application installation method 700 is applied to another application distribution system, which includes terminal device A1, terminal device A2, and server B1. Terminal device A1 is, for example, a device used by a developer, and terminal device A2 is a device used to install the target application. Terminal device A2 has deployment tools and installation tools. Server B1 may be a server that has deployed an application marketplace. Server B1 establishes communication connections with both terminal device A1 and terminal device A2. The application installation method 700 includes steps S701 to S711. This method 700 does not rely on... Figure 7 The specific order is a limitation. It should be understood that in other embodiments, the order of some steps in method 700 can be interchanged according to actual needs, or some steps can be omitted or deleted. The following is a detailed explanation of each step of method 700.

[0149] S701 and terminal device A1 use the developer's private key to sign the hash value of the target application's installation package to obtain the developer's signature.

[0150] It should be noted that the implementation process of S701 is the same as that of S301. For details, please refer to the implementation process of S301. The embodiments of this application will not be described again here.

[0151] S702, Terminal device A1 sends the developer signature, installation package, hash value of the installation package, and profile file of the target application to terminal device A2. Correspondingly, terminal device A2 receives the developer signature, installation package, hash value of the installation package, and profile file of the target application.

[0152] The Profile file can be a file requested by the terminal device A1 from the app store to describe the target application. This Profile file includes the developer certificate, the target application's ID, other information about the target application, and a Profile file signature. The Profile file signature is a signature from the app store, used to prove that the target application's identity is recognized by the app store.

[0153] S703 and terminal device A2 obtain the developer's signature, installation package, hash value of the installation package, and profile file of the target application from the local machine through the deployment tool.

[0154] S704 and terminal device A2 verify the developer's signature through the deployment tool, and if the verification is successful, determine whether the installation package has been tampered with based on the hash value of the installation package.

[0155] In one possible implementation, a deployment tool verifies the developer certificate using the root public key. If verification is successful, it indicates the developer certificate has not been tampered with (i.e., the developer certificate is legitimate or trustworthy). The developer certificate can be sent from terminal device A1 to terminal device A2. Next, terminal device A2 can extract the developer's public key from the developer certificate and verify the developer's signature using the developer's public key. If verification is successful, terminal device A2 can hash the installation package to obtain a first hash value and compare the hash value of the received installation package with this first hash value. If the hash value of the received installation package matches the first hash value, it indicates the installation package has not been tampered with.

[0156] S705 and terminal device A2 perform security checks on the installation package using deployment tools, provided the installation package has not been tampered with.

[0157] In one possible implementation, terminal device A2 invokes a security scanning tool through a deployment tool, and the security scanning tool performs security checks on the installation package. These security checks may include detecting whether the installation package contains malicious code or viruses.

[0158] S706. If the security test is passed, the terminal device A1 uses the private key of XX person to sign the second target data through the deployment tool to obtain the deployment signature of XX person. The second target data includes the hash value of the installation package, the account of XX person and the device SN.

[0159] The XX personal deployment certificate carries the public key of XX individual and is used to verify the XX individual's deployment signature. The private key of XX individual can also be referred to as the private key corresponding to the XX personal deployment certificate. The second target data is used to authorize the installation of the target application on devices managed by XX individual. Alternatively, the first target data can be understood as authorizing the target application to be installed on devices managed by XX individual.

[0160] The XX Personal Deployment Certificate can be issued by the app store to XX Personal. It is also known as the XX Personal Deployment Certificate. The XX Personal Deployment Certificate proves that XX Personal has the authority to deploy applications on devices managed by XX Personal. The XX Personal's account and device serial number (SN) uniquely identify the devices managed by XX Personal.

[0161] Figure 8 This is a schematic diagram of another certificate issuance chain provided in an embodiment of this application. In a certificate issuance system, the root certificate is the highest-level certificate, and it has the authority to issue other certificates. Figure 8 As shown, the root certificate first issues developer certificates and deployment certificates. The deployment certificate then issues app store deployment certificates and personal deployment certificates, and the personal deployment certificate further issues XX personal deployment certificates. The app store can manage developer certificates, deployment certificates, app store deployment certificates, personal deployment certificates, and XX personal deployment certificates.

[0162] In one possible implementation, terminal device A2 can send a request to server B1 to obtain a personal deployment certificate for XX. This request includes the XX individual's account, device serial number (SN), and public key. Server B1, in response to the request, generates the personal deployment certificate through an application marketplace and sends it to terminal device A2.

[0163] For example, Figure 9 This is a schematic diagram illustrating the structure of the XX personal deployment certificate provided in an embodiment of this application. (See attached diagram.) Figure 9 As shown, the XX personal deployment certificate includes the XX individual's account, device serial number (SN), personal public key, and certificate signature. The XX personal deployment certificate is in X.509 format.

[0164] Figure 10 This diagram illustrates the two-stage signing process of the target application in another application installation method provided in this application embodiment. Figure 10As shown, the developer can use their private key to sign the hash value of the target application's installation package on terminal device A1 (i.e., the first signature), obtaining the developer signature; this developer signature can also be called the installation developer signature. Subsequently, the developer uses terminal device A1 to generate a compressed package based on the developer signature, the installation package, the installation package's hash value, and the profile file, and sends this compressed package to terminal device A2. The deployment tool on terminal device A2 can retrieve this compressed package locally and decompress it, obtaining the developer signature, the installation package, the installation package's hash value, and the profile file. The deployment tool verifies the developer signature based on the developer certificate. If the verification is successful, it determines whether the installation package has been tampered with based on the installation package's hash value. If the installation package has not been tampered with, a security check is performed on the installation package. If the security check passes, the private key of individual XX is used to sign the hash value of the installation package, the individual's account, and the device SN, obtaining the individual deployment signature; this individual deployment signature can be abbreviated as the individual signature. In this way, by using the deployment tools on the terminal device to perform security checks and sign the installation package, the installation tools on the terminal device can install the installation package that has passed the security check, thereby reducing the security risks faced by the target application during installation.

[0165] S707, Terminal device A2 uses a deployment tool to send the XX personal deployment signature, installation package and Profile file, and second target data to the installation tool of terminal device A2.

[0166] S708 and terminal device A2 verify the XX personal deployment signature using an installation tool, based on the certificate chain and root public key. The certificate chain includes the XX personal deployment certificate.

[0167] For example, such as Figure 8 As shown, the certificate chain includes a deployment certificate, a personal deployment certificate, and a third personal deployment certificate (XX). Terminal device A2 can use the root public key to verify the certificate chain. First, the deployment certificate is verified using the root public key. If the deployment certificate verification is successful, the deployment public key is extracted from it. Next, the personal deployment certificate is verified using the deployment public key. If the personal deployment certificate verification is successful, the personal deployment public key is extracted from it, and then used to verify the third personal deployment certificate (XX). If the third personal deployment certificate verification is successful, the third personal's public key is extracted from it. Finally, the third personal's public key is used to verify the third personal deployment signature.

[0168] S709. If the signature verification for XX personal deployment passes, the received installation package is hashed using the installation tool to obtain a new hash value.

[0169] This new hash value can be represented as the second hash value.

[0170] S710. If the signature verification of XX person is successful, the installation tool determines whether terminal device A2 belongs to the device managed by XX person based on XX person's account and device SN.

[0171] The account of XX person is used to uniquely identify XX person. The account and device serial number of XX person are used to uniquely identify the device managed by XX person.

[0172] For example, the account of the individual to which terminal device A2 belongs can be matched with the account of individual XX, and the device SN of terminal device A2 can be compared with the device SN in the second target data. If the account of the individual to which terminal device A2 belongs matches (i.e., is consistent) with the account of individual XX, and the device SN of terminal device A2 matches (is consistent) with the device SN in the second target data, it is determined that terminal device A2 belongs to the device managed by individual XX.

[0173] S711. If the new hash value is consistent with the hash value in the second target data, and the terminal device A2 belongs to the device managed by XX, install the target application based on the received installation package using the installation tool, and output the detailed information of the installed target application based on the Profile file.

[0174] It should be noted that the descriptions of the same steps and contents in the embodiments of this application as in other embodiments can be referred to the descriptions in other embodiments, and will not be repeated here.

[0175] This application provides an application installation method. When the terminal device A2 installs the target application, the installation package used is verified by security testing and confirmed by the private key signature of XX individuals. Installing the target application based on this installation package can reduce the possibility of malicious application installation, reduce installation risks, and improve the overall user experience.

[0176] Figure 11 This is a flowchart illustrating an application installation method 1100 provided in an embodiment of this application, as shown below. Figure 11 As shown, the application installation method 1100 includes steps S1101 to S1103. This method 1100 is applied to a first terminal device, such as terminal device A2 in method 300 or method 700. This method 1100 does not... Figure 11 The specific order is a limitation. It should be understood that in other embodiments, the order of some steps in method 1100 can be interchanged according to actual needs, or some steps can be omitted or deleted. The following is a detailed explanation of each step of method 1100.

[0177] S1101. Obtain the installation package of the target application, the target data, and the first signature corresponding to the target data.

[0178] The first signature is obtained by signing the target data after the installation package passes the security test. The target data includes the identifier of the device managed by the trusted object.

[0179] In this embodiment, the installation package of the target application can be received by the first terminal device; the target data and the first signature corresponding to the target data can be received by the first terminal device or determined by the first terminal device. The installation package of the target application can be an installation package in an intermediate state during the development of the target application. Alternatively, the installation package of the target application can be an installation package of a customized application purchased by the enterprise. A trusted object refers to an entity that is deemed secure, reliable, and trustworthy. A trusted object can be a target individual or a target enterprise. For example, a target individual can be XX individuals, and a target enterprise can be XX enterprises.

[0180] In one possible implementation, the identifier of the device managed by the trusted object is used to uniquely identify the device managed by the trusted object. This identifier can consist of two parts: the identifier of the trusted object and the device identifier, such as a device serial number (SN). The target application is an application authorized to be installed on the device managed by the trusted object.

[0181] The first signature can be obtained by signing the target data with the private key of a trusted object, provided that the installation package passes security checks.

[0182] In one possible implementation, the target data also includes information for identifying the installation package, and the target data is used to authorize the installation of the target application on devices managed by the trusted object.

[0183] Based on the above scheme, by binding the information used to identify the installation package with the identifier of the device managed by the trusted object, the installation of the target application is authorized on the device managed by the trusted object. This ensures that the target application can only be installed and run on the device managed by the trusted object, thereby improving the security of the target application and preventing its abuse.

[0184] In one possible implementation, this information is used to uniquely identify the installation package of the target application; this information may be, for example, a first hash value. This not only ensures the uniqueness of the installation package but also effectively protects it from tampering during security checks and transmission to the first terminal device. The first hash value may, for example, be the hash value in the first target data in method 300 described above. Alternatively, the first hash value may, for example, be the hash value in the second target data in method 700 described above.

[0185] For example, the installation package of the target application, the target data, and the first signature corresponding to the target data can be received by the first terminal device. The first terminal device can be terminal device A2 in method 300, and the installation package of the target application, the target data, and the first signature corresponding to the target data can be sent from server B2 to terminal device A2 in method 300. The target data can be the first target data in method 300, and the first signature can be the internal application market signature of MM Enterprise.

[0186] In another example, the installation package of the target application can be received by a first terminal device, and the target data and the first signature corresponding to the target data can be determined by the first terminal device. Here, the first terminal device can be terminal device A2 in method 700, and the installation package of the target application can be sent by terminal device A1 in method 700. The target data and the first signature corresponding to the target data can be determined by the deployment tool of terminal device A2. The first signature can be the XX personal deployment signature in method 700, and the target data can be the second target data in method 700.

[0187] S1102. Verify the first signature based on the target deployment certificate.

[0188] The target deployment certificate is used to prove that a trusted object has the authority to deploy applications on devices managed by the trusted object. The target deployment certificate carries the public key of the trusted object, which corresponds to the private key of the trusted object. The target data includes the identifier of the device managed by the trusted object.

[0189] In one possible implementation, a certificate chain can be received, from which the target deployment certificate can be obtained. Subsequently, the public key of a trusted object is extracted from the target deployment certificate, and the public key of the trusted object is used to verify the first signature. If the first signature verification passes, it indicates that the integrity check has passed, meaning the target data is tamper-proof and trustworthy. The target deployment certificate can be an end-of-chain certificate.

[0190] In one possible implementation, the trusted object is the first object, the first object is the target individual, and the target deployment certificate can be the first deployment certificate.

[0191] For example, the target individual is XX individuals, the first deployment certificate is the deployment certificate of XX individuals, the deployment certificate of XX individuals carries the public key of XX individuals, and the first signature is the deployment signature of XX individuals in method 700. This deployment signature of XX individuals can be referred to as the signature of XX individuals. Figure 8 As shown, the certificate chain includes a deployment certificate, a personal deployment certificate, and an XX personal deployment certificate. Specifically, the deployment certificate issued the personal deployment certificate, and the personal deployment certificate issued the XX personal deployment certificate.

[0192] In one possible implementation, the trusted object is a second object, which is the target enterprise, and the target deployment certificate can be the second deployment certificate.

[0193] For example, the target individual is MM Enterprise, the second deployment certificate is the MM Enterprise deployment certificate, which carries the MM Enterprise's public key, and the first signature is the MM Enterprise's internal application marketplace signature in method 300. This MM Enterprise's internal application marketplace signature can be referred to as the MM Enterprise's signature. Figure 4 As shown, the certificate chain includes a deployment certificate, an enterprise application marketplace deployment certificate, and an MM enterprise deployment certificate. Specifically, the deployment certificate was issued as an enterprise application marketplace deployment certificate, and the enterprise application marketplace deployment certificate was issued as an MM enterprise deployment certificate.

[0194] In one possible implementation, the target deployment certificate is in X.509 format.

[0195] S1103. If the first signature verification is successful and the first terminal device is determined to be a device managed by the trusted object based on the identifier of the device managed by the trusted object, the target application is installed based on the installation package.

[0196] The number of devices managed by the trusted object is at least one.

[0197] In this embodiment of the application, if the verification is successful, it can be determined whether the first terminal device belongs to the device managed by the trusted object based on the identifier of the device managed by the trusted object in the target data.

[0198] In one possible implementation, the identifier of the device managed by the trusted object can consist of two parts: the identifier of the trusted object and at least one device serial number (SN). The first terminal device can match the identifier of the object to which it belongs with the identifier of the trusted object, and match the device serial number of the first terminal device with at least one device serial number. If the identifier of the object to which the first terminal device belongs matches (i.e., is consistent) with the identifier of the trusted object, and at least one of the at least one device serial numbers matches (i.e., is consistent) with the device serial number of the first terminal device, then it is determined that the first terminal device belongs to the device managed by the trusted object.

[0199] For example, a trusted object could be a company called MM, and the identifier of the trusted object could be the ID of MM. Similarly, a trusted object could be an individual called XX, and the identifier of the trusted object could be the account of that individual.

[0200] In this embodiment, when installing a target application based on an installation package, detailed information about the target application can be output based on the target application's profile file. The target application's profile file can originate from either terminal device A1 or server B2. This allows users to access detailed information about the target application, such as its name, version, developer, and feature description, thus enhancing their understanding of the application.

[0201] It should be noted that the descriptions of the same steps and contents in the embodiments of this application as in other embodiments can be referred to the descriptions in other embodiments, and will not be repeated here.

[0202] This application provides an application installation method. The method involves obtaining an installation package for the target application, target data, and a first signature corresponding to the target data. The first signature is obtained by signing the target data after the installation package passes security checks. The first signature is verified based on a target deployment certificate, which proves that a trusted object has the authority to deploy applications on devices managed by the trusted object. The target data includes the identifier of the device managed by the trusted object. If the first signature verification is successful and the identifier of the device managed by the trusted object confirms that the first terminal device belongs to a device managed by the trusted object, the target application is installed based on the installation package. Thus, the installation package used when installing the target application on the first terminal device has passed security checks. Installing the target application based on the installation package can prevent the injection of malicious code, ensure the normal operation of the target application and data security, and improve the overall security and reliability of the system.

[0203] Figure 12 This is a flowchart illustrating an application installation method 1200 provided in an embodiment of this application, as shown below. Figure 12 As shown, the application installation method includes steps S1201 to S1210. Step 1200 does not... Figure 12 The specific order is a limitation. It should be understood that in other embodiments, the order of some steps in method 1200 can be interchanged according to actual needs, or some steps can be omitted or deleted. In application installation method 1200, the first terminal device can be terminal device A2 in method 700, the second terminal device can be terminal device A1 in method 700, and the first server can be server B1 in method 700. The following provides a detailed explanation of each step of method 1200.

[0204] S1201, the first terminal device sends a first acquisition request to the first server, the first acquisition request being used to acquire the first deployment certificate. Correspondingly, the first server receives the first acquisition request.

[0205] The first deployment certificate is used to prove that the first object has the authority to deploy applications on the devices managed by the first object. Deploying applications includes at least one of installing applications, configuring applications, and running applications.

[0206] S1202, the first server sends a first deployment certificate to the first terminal device based on the first acquisition request. Correspondingly, the first terminal device receives the first deployment certificate.

[0207] In this embodiment, the first server can generate a first deployment certificate based on a first acquisition request. The first acquisition request carries an identifier of the first object, a device serial number (SN) of the device managed by the first object, and the public key of the first object. The identifier of the first object is used to uniquely identify the first object. The first deployment certificate carries the identifier of the first object, the SN of the device managed by the first object, the public key of the first object, and a certificate signature, which is the signature of the application marketplace of the first server.

[0208] For example, the first object is the target individual, such as XX individuals, and the first deployment certificate is the deployment certificate for XX individuals. Figure 9 As shown, the XX personal deployment certificate includes the XX personal account, device serial number, personal public key, and certificate signature.

[0209] It should be noted that S1201-1202 is the process by which the first terminal device applies for a first deployment certificate from the application market. After obtaining this first deployment certificate, the first terminal device can deploy a specific application on the device managed by the first object. S1203-S1210 are schematic diagrams of the process of deploying the target application on the device managed by the first object after obtaining the first deployment certificate.

[0210] S1203, the second terminal device sends the installation package of the target application and the second signature corresponding to the installation package to the first terminal device. Correspondingly, the first terminal device receives the installation package and the second signature corresponding to the installation package.

[0211] S1204. The first terminal device uses its deployment tool to determine whether the installation package has been tampered with based on the second signature.

[0212] In one possible implementation, the second signature can be obtained by the second terminal device signing the second hash value of the installation package using the developer's private key. The second hash value of the installation package is obtained by the second terminal device after hashing the installation package. The first terminal device verifies the developer certificate using its deployment tool and the root public key. If the developer certificate is valid, the developer's public key is extracted from the developer certificate. Subsequently, the second signature is verified using the developer's public key. If the verification is successful, it indicates that the second hash value of the received installation package has not been tampered with. The first terminal device can hash the received installation package and compare the hash value obtained from the hashing process with the second hash value. If the hash value obtained from the hashing process matches the second hash value, it is determined that the received installation package has not been tampered with. If the hash value obtained from the hashing process does not match the second hash value, it is determined that the installation package has been tampered with.

[0213] S1205. The first terminal device performs a security check on the installation package using its deployment tool, provided the installation package has not been tampered with.

[0214] In this embodiment, a security scanning tool can be invoked through a deployment tool to perform security checks on the installation package. These security checks may include detecting whether the installation package contains malicious code or viruses.

[0215] S1206. If the security test is passed, the target data is obtained by using the deployment tool of the first terminal device, and the target data is signed based on the private key of the first object to obtain the first signature.

[0216] Among these, passing the security test means that the installation package does not contain malicious code or viruses.

[0217] In one possible implementation, the target data includes a first hash value of the installation package and an identifier of the device managed by the first object. The identifier of the device managed by the first object includes the identifier of the first object and the device serial number (SN). The target data is used to authorize the installation of the target application on the device managed by the first object. Here, the first object is the target individual, such as XX individuals. The first hash value is obtained by hashing the installation package using the deployment tool on the first terminal device.

[0218] For example, the identifier of the first object may be, for instance, an account belonging to an individual. The target data may be, for instance, the second target data described in method 700.

[0219] S1207. The installation package, target data, and the first signature corresponding to the target data are provided to the installation tool of the first terminal device through the deployment tool of the first terminal device.

[0220] S1208. The first terminal device receives a certificate chain through its installation tool, obtains a first deployment certificate from the certificate chain, and verifies the first signature based on the first deployment certificate.

[0221] The first target is the individual, for example, XX individuals. The first deployment certificate is the deployment certificate for XX individuals, such as... Figure 8 As shown, the certificate chain includes deployment certificate, personal deployment certificate, and XX personal deployment certificate.

[0222] In this embodiment, the certificate chain can be verified using the installation tool on the first terminal device. If the certificate chain is valid, a first deployment certificate is obtained from the certificate chain, and the public key of the first object is extracted from the first deployment certificate. The public key of the first object is then used to verify the first signature. If the verification passes, it indicates that the target data has not been tampered with (i.e., the target data is trustworthy).

[0223] The certificate chain can be pre-sent by the first server to the first terminal device and then provided to the installation tool through the deployment tool of the first terminal device.

[0224] S1209. Using the installation tool of the first terminal device, if the first signature verification is successful, determine whether the installation package has been tampered with based on the first hash value and whether the first terminal device belongs to the device managed by the first object based on the identifier of the device managed by the first object.

[0225] In this embodiment, if the first signature verification passes, the installation tool hashes the installation package and compares the hash value obtained with a first hash value. If the hash value and the first hash value match, it indicates that the installation package received by the installation tool has not been tampered with. If the hash value and the first hash value do not match, it indicates that the installation package received by the installation tool has been tampered with. The first hash value is used to prevent the installation package from being tampered with during transmission from the deployment tool to the installation tool.

[0226] In one possible implementation, the identifier of the device managed by the first object can consist of two parts: the identifier of the first object and the device serial number (SN) of the device managed by the first object. The first terminal device can compare the identifier of the object to which it belongs with the identifier of the first object, and compare the device serial number of the first terminal device with the device serial number of the device managed by the first object. If the identifier of the object to which the first terminal device belongs matches the identifier of the first object, and one of the device serial numbers of the devices managed by the first object matches the device serial number of the first terminal device, then the first terminal device is determined to belong to the device managed by the first object. The identifier of the first object could be, for example, an account belonging to an individual.

[0227] S1210. Using the installation tool of the first terminal device, if the installation package has not been tampered with and the first terminal device belongs to the device managed by the first object, install the target application based on the installation package.

[0228] It should be noted that the descriptions of the same steps and contents in the embodiments of this application as in other embodiments can be referred to the descriptions in other embodiments, and will not be repeated here.

[0229] This application provides an application installation method. When the first terminal device installs the target application, the installation package used is verified by security testing and confirmed by the private key signature of the first object. Installing the target application based on this installation package can reduce the possibility of malicious application installation, reduce installation risk, and improve the overall user experience.

[0230] Figure 13 This is a flowchart illustrating an application installation method 1300 provided in an embodiment of this application, as shown below. Figure 13 As shown, the application installation method includes steps S1301 to S1310. Step 1300 does not... Figure 13 The specific order is a limitation. It should be understood that in other embodiments, the order of some steps in method 1300 can be interchanged according to actual needs, or some steps can be omitted or deleted. In application installation method 1300, the first terminal device can be terminal device A2 in method 300, the second terminal device can be terminal device A1 in method 300, and the first server can be server B1 in method 300. The second server can be server B2 in method 300. The following provides a detailed explanation of each step of method 1300.

[0231] S1301, The second server sends a second retrieval request to the first server, the second retrieval request being used to obtain the second deployment certificate. Correspondingly, the first server receives the second retrieval request.

[0232] The second deployment certificate is used to prove that the second object has the authority to deploy applications on the devices managed by the second object. Deploying applications includes at least one of installing applications, configuring applications, and running applications.

[0233] S1302, The first server sends the second deployment certificate to the second server based on the second acquisition request. Accordingly, the second server receives the second deployment certificate.

[0234] In this embodiment, the first server can generate a second deployment certificate based on a second acquisition request. The second acquisition request carries an identifier of the second object, a device serial number (SN) of the device managed by the second object, and the public key of the second object. The identifier of the second object is used to uniquely identify the second object. The second deployment certificate carries the identifier of the second object, the SN of the device managed by the second object, the public key of the second object, and a certificate signature, which is the signature of the application market of the first server.

[0235] For example, the second object is the target enterprise, such as MM Enterprise, and the second deployment certificate is the MM Enterprise deployment certificate. Figure 5 As shown, the MM enterprise deployment certificate includes the MM enterprise's ID, SN list, enterprise public key, and certificate signature, which is the application market's signature.

[0236] It should be noted that S1301-1302 describes the process by which the first server applies for a second deployment certificate from the application market. After obtaining this first deployment certificate, the first server can deploy a specific application on the device managed by the second object. S1303-S1310 are schematic diagrams of the process of deploying the target application on the device managed by the second object after obtaining the second deployment certificate.

[0237] S1303, the second terminal device sends the installation package of the target application and the second signature corresponding to the installation package to the second server. Correspondingly, the second server receives the installation package and the second signature corresponding to the installation package.

[0238] S1304. The second server determines whether the installation package has been tampered with based on the second signature.

[0239] In one possible implementation, the second signature can be obtained by the second terminal device signing the second hash value of the installation package using the developer's private key. The second hash value of the installation package is obtained by the second terminal device hashing the installation package. The second server can verify the developer's certificate using the root public key. If the developer's certificate is valid, the server extracts the developer's public key from the developer's certificate. Subsequently, the server verifies the second signature using the developer's public key. If the verification passes, it indicates that the second hash value of the received installation package has not been tampered with. The second server can hash the received installation package and compare the hash value obtained from the hashing process with the second hash value. If the hash value obtained from the hashing process matches the second hash value, it is determined that the received installation package has not been tampered with. If the hash value obtained from the hashing process does not match the second hash value, it is determined that the installation package has been tampered with.

[0240] S1305. Perform a security check on the installation package if it has not been tampered with.

[0241] In this embodiment, the second server can perform security checks on the installation package using a security scanning tool. These security checks may include detecting whether the installation package contains malicious code or viruses.

[0242] S1306. If the security test is passed, the second server obtains the target data and signs the target data based on the private key of the second object to obtain the first signature. The target data includes the first hash value of the installation package and the identifier of the device managed by the second object.

[0243] Among these, passing the security test means that the installation package does not contain malicious code or viruses.

[0244] In one possible implementation, the target data includes a first hash value of the installation package and an identifier of the device managed by the second object. The identifier of the device managed by the second object includes the identifier of the second object and the device serial number (SN). The target data is used to authorize the installation of the target application on the device managed by the second object. Here, the second object is the target enterprise, such as MM Enterprise.

[0245] For example, the identifier of the second object is, for instance, the ID of the MM enterprise. The target data is specifically, for instance, the first target data in method 300.

[0246] S1307, the second server sends the installation package, target data, and first signature to the first terminal device. Correspondingly, the first terminal device receives the installation package, target data, and first signature.

[0247] In this embodiment, the installation package, target data, and first signature can be sent proactively by the second server to the first terminal device, or they can be sent by the second server in response to an acquisition request from the first terminal device. The acquisition request carries an identifier of the target application, which is used to uniquely identify the target application. This acquisition request is used to acquire the installation package of the target application.

[0248] S1308. The first terminal device receives the certificate chain, obtains the second deployment certificate from the certificate chain, and verifies the first signature based on the second deployment certificate.

[0249] The second object is the target enterprise, such as MM enterprise. The second deployment certificate is the MM enterprise deployment certificate, such as... Figure 4 As shown, the certificate chain includes the deployment certificate, the enterprise application marketplace deployment certificate, and the MM enterprise deployment certificate.

[0250] In this embodiment, the certificate chain can be verified. If the certificate chain is valid, a second deployment certificate is obtained from the certificate chain, and the public key of the second object is extracted from the second deployment certificate. Subsequently, the public key of the second object is used to verify the first signature. If the verification passes, it indicates that the target data has not been tampered with (i.e., the target data is trustworthy).

[0251] S1309. If the first signature verification is successful, the first terminal device determines whether the installation package has been tampered with based on the first hash value and whether the first terminal device belongs to the device managed by the second object based on the identifier of the device managed by the second object.

[0252] In this embodiment, if the first signature verification passes, the first terminal device performs hash processing on the installation package and compares the hash value obtained from the hash processing with the first hash value. If the hash value obtained from the hash processing and the first hash value match, it indicates that the received installation package has not been tampered with. If the hash value obtained from the hash processing and the first hash value do not match, it indicates that the received installation package has been tampered with. The first hash value is used to prevent tampering during the transmission of the installation package from the second server to the first terminal device.

[0253] In one possible implementation, the identifier of the device managed by the second object can consist of two parts: the identifier of the second object and the device serial number (SN) of the device managed by the second object. The first terminal device can compare the identifier of the object to which it belongs with the identifier of the second object, and compare the device serial number of the first terminal device with the device serial number of the device managed by the second object. If the identifier of the object to which the first terminal device belongs matches the identifier of the second object, and one of the device serial numbers of the device managed by the second object matches the device serial number of the first terminal device, then the first terminal device is determined to belong to the device managed by the second object. The identifier of the second object, for example, is the ID of enterprise XX.

[0254] S1310. If the installation package has not been tampered with and the first terminal device belongs to the device managed by the second object, install the target application based on the installation package.

[0255] It should be noted that the descriptions of the same steps and contents in the embodiments of this application as in other embodiments can be referred to the descriptions in other embodiments, and will not be repeated here.

[0256] This application provides an application installation method. When the first terminal device installs the target application, the installation package used has passed security testing. Installing the target application based on this installation package can reduce the possibility of malicious application installation, reduce installation risks, and improve the overall user experience.

[0257] Based on the foregoing embodiments, in methods 300, 700, 1100, 1200 and 1300, the first terminal device (terminal device A2) may perform the following steps before receiving the installation package of the target application: in response to a user operation, start the target installation function, which is a function that only allows the installation of applications from trusted objects.

[0258] For example, the settings interface of the first terminal device has a tab for user management of application installation functions. Users can click this tab to enter the installation function configuration interface. Figure 14 This is a schematic diagram of the installation function configuration interface of the first terminal device in an application installation method provided in this application embodiment, as shown below. Figure 14 As shown, users can click the "Recognized Applications" option in the installation function configuration interface to start the target installation function. This allows the first terminal device to be configured to trust the signature of a trusted object. Upon receiving the installation package, if the signature of the trusted object (i.e., the first signature) is verified and the first terminal device belongs to a device managed by the trusted object, the target application will be installed based on the installation package. This reduces the possibility of malicious application installation, lowers installation risks, and improves the overall user experience.

[0259] The above combination Figure 3 , Figure 7 , Figure 11 , Figure 12 and Figure 13 This application describes the application installation method provided in the embodiments of this application. In the various embodiments of this application, unless otherwise specified or logically conflicting, the terms and / or descriptions between the various embodiments are consistent and can be referenced by each other. The technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationship.

[0260] It is understood that, in order to achieve the above-mentioned functions, electronic devices include hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application. This application can divide the application installation method into functional units according to the above method examples; for example, each function can be divided into separate functional units, or two or more functions can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. It should be noted that the unit division in this application is illustrative and only represents one logical functional division; other division methods may exist in actual implementation.

[0261] The following is combined Figure 15 This application provides a detailed description of the electronic device provided in its embodiments. It should be understood that the descriptions of the device embodiments correspond to the descriptions of the method embodiments; therefore, any content not described in detail can be found in the above method embodiments, and for the sake of brevity, will not be repeated here.

[0262] Figure 15 A schematic diagram of the structure of an electronic device provided in this application is shown. Figure 15 The dashed line indicates that the unit or module is optional. Electronic device 15 can be used to implement the methods described in the above method embodiments. Electronic device 15 can be a first terminal device, a second terminal device, a first server, a second server, or a chip (system).

[0263] The electronic device 15 includes one or more processors 1501, which can support the electronic device 15 in implementing the methods described in the above-described method embodiments. The processor 1501 can be a general-purpose processor or a special-purpose processor. For example, the processor 1501 can be a central processing unit (CPU). The CPU can be used to control the electronic device 15, execute software programs, and process data from the software programs. The electronic device 15 may also include a communication unit 1505 for implementing signal input (reception) and output (transmission).

[0264] The aforementioned electronic device 15 may be a chip (system) including a memory and a processor, wherein the processor is configured to execute a computer program stored in the memory to implement the methods shown in the various embodiments above.

[0265] The communication unit 1505 may be an input and / or output circuit of the chip (system), or the communication unit 1505 may be a communication interface of the chip (system), which may be a component of the electronic device 15.

[0266] For example, the communication unit 1505 may be a transceiver of the electronic device 15, or the communication unit 1505 may be a transceiver circuit of the electronic device 15. The electronic device 15 may include one or more memories 1502, on which a program 1504 is stored. The program 1504 can be executed by the processor 1501 to generate instructions 1503, causing the processor 1501 to execute the method described in the above method embodiments according to the instructions 1503. Optionally, the memory 1502 may also store data. Optionally, the processor 1501 may also read data stored in the memory 1502, which may be stored at the same memory address as the program 1504, or the data may be stored at a different memory address than the program 1504.

[0267] The processor 1501 and memory 1502 can be configured separately or integrated together, for example, integrated on a system-on-chip (SOC) of an electronic device. For details on how the processor 1501 executes the application installation method, please refer to the relevant description in the method embodiments.

[0268] It should be understood that the steps of the above method embodiments can be implemented by hardware logic circuits or software instructions in the processor 1501. The processor 1501 may be a CPU, a digital signal processor (DSP), a field programmable gate array (FPGA), or other programmable logic devices, such as discrete gate, transistor logic devices, or discrete hardware components.

[0269] This application also provides a computer program product that, when executed by processor 1501, implements the method of any method embodiment in this application. The computer program product can be stored in memory 1502, for example, as program 1504. Program 1504 undergoes preprocessing, compilation, assembly, and linking processes to ultimately be converted into an executable object file that can be executed by processor 1501.

[0270] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a computer, implements the method of any of the method embodiments of this application. The computer program may be a high-level language program or an executable object program.

[0271] The computer-readable storage medium is, for example, memory 1502. Memory 1502 can be volatile memory or non-volatile memory, or memory 1502 can include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DRRAM).

[0272] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process and technical effects of the above-described apparatus and equipment can be referred to the corresponding processes and technical effects in the foregoing method embodiments, and will not be repeated here.

[0273] The systems, apparatuses, and methods disclosed in the embodiments provided in this application can be implemented in other ways. For example, some features of the method embodiments described above may be omitted or not performed. The apparatus embodiments described above are merely illustrative; the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Multiple units or components may be combined or integrated into another system. Furthermore, the coupling between units or components can be direct or indirect, including electrical, mechanical, or other forms of connection.

[0274] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

[0275] Finally, the above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. An application installation method, characterized in that, Applied to a first terminal device, the method includes: The installation package of the target application, the target data, and the first signature corresponding to the target data are obtained. The first signature is obtained by signing the target data after the installation package passes the security test. The first signature is verified based on the target deployment certificate, which is used to prove that the trusted object has the authority to deploy applications on the devices managed by the trusted object. The target data includes the identifier of the devices managed by the trusted object. If the first signature verification is successful, and the first terminal device is determined to belong to the device managed by the trusted object based on the identifier of the device managed by the trusted object, the target application is installed based on the installation package.

2. The method according to claim 1, characterized in that, The target data also includes information for identifying the installation package, and the target data is used to authorize the devices managed by the trusted object to install the target application.

3. The method according to claim 2, characterized in that, The information is the first hash value of the installation package, which is used to prevent the installation package from being tampered with.

4. The method according to any one of claims 1 to 3, characterized in that, The target deployment certificate is obtained through the following methods: Receive certificate chain; Obtain the target deployment certificate from the certificate chain.

5. The method according to any one of claims 1 to 3, characterized in that, The method further includes receiving a certificate chain, the certificate chain including the target deployment certificate and at least one of the following certificates: a deployment certificate, an enterprise application market deployment certificate, and a personal deployment certificate.

6. The method according to any one of claims 1 to 5, characterized in that, The target deployment certificate includes the identifier of the device managed by the trusted object.

7. The method according to any one of claims 1 to 6, characterized in that, The trusted object is a first object, and the target deployment certificate is a first deployment certificate. The first deployment certificate is used to prove that the first object has the authority to deploy applications on the devices managed by the first object. Obtaining the installation package of the target application, the target data, and the first signature corresponding to the target data includes: Receive the installation package from the second terminal device; If the installation package passes the security test, the target data is obtained through the deployment tool of the first terminal device, and the target data is signed based on the private key corresponding to the first deployment certificate to obtain the first signature.

8. The method according to claim 7, characterized in that, The first deployment certificate was obtained in the following way: Send a first retrieval request to the first server, the first retrieval request being used to retrieve the first deployment certificate; Receive the first deployment certificate from the first server.

9. The method according to claim 7 or 8, characterized in that, The method further includes: Receive the second signature corresponding to the installation package from the second terminal device; If the installation package is determined to be untampered based on the second signature, the installation package is subjected to security testing using the deployment tool of the first terminal device.

10. The method according to any one of claims 1 to 6, characterized in that, The trusted object is a second object, and the target deployment certificate is a second deployment certificate. The second deployment certificate is used to prove that the second object has the authority to deploy applications on the devices managed by the second object. The step of obtaining the installation package of the target application, the target data, and the first signature corresponding to the target data includes: The installation package, the target data, and the first signature are received from the second server.

11. An application installation method, characterized in that, Applied to a second server, the method includes: Receive the installation package of the target application from the second terminal device; If the installation package passes the security test, the target data is obtained and the target data is signed based on the private key corresponding to the second deployment certificate to obtain a first signature. The second deployment certificate is used to prove that the second object has the right to deploy applications on the devices managed by the second object. The target data includes the identifier of the devices managed by the second object. The installation package, the target data, and the first signature are sent to the first terminal device.

12. The method according to claim 11, characterized in that, The target data also includes information for identifying the installation package, and the target data is used to authorize the devices managed by the second object to install the target application.

13. The method according to claim 12, characterized in that, The information is the first hash value of the installation package, which is used to prevent the installation package from being tampered with.

14. The method according to any one of claims 11 to 13, characterized in that, The second deployment certificate was obtained in the following way: Send a second retrieval request to the first server, the second retrieval request being used to retrieve the second deployment certificate; Receive the second deployment certificate from the first server, the second deployment certificate including the identifier of the device managed by the second object.

15. The method according to any one of claims 10 to 14, characterized in that, The method further includes: Receive the second signature corresponding to the installation package; If the installation package is determined to be untampered based on the second signature, a security check is performed on the installation package.

16. An application installation method, characterized in that, Applied to a first server, the method includes: Receive an acquisition request, the acquisition request being used to acquire the target deployment certificate; Based on the request, the target deployment certificate is sent. The target deployment certificate is used to prove that the trusted object has the authority to deploy applications on the devices managed by the trusted object. The target deployment certificate includes the identifier of the devices managed by the trusted object.

17. The method according to claim 16, characterized in that, The trusted object is either a first object or a second object, wherein the first object is a target individual and the second object is a target enterprise.

18. An electronic device, characterized in that, include: A memory, one or more processors, and one or more programs; wherein the one or more programs are stored in the memory; When the one or more processors execute the one or more programs, they cause the electronic device to perform the method of any one of claims 1 to 10, any one of claims 11 to 15, or any one of claims 16 to 17.

19. A chip system, characterized in that, The chip system includes a memory and a processor, the processor being configured to execute a computer program stored in the memory to implement the method as claimed in any one of claims 1 to 10, 11 to 15, or 16 to 17.

20. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed, they cause the computer to perform the method as described in any one of claims 1 to 10, 11 to 15, or 16 to 17.

21. A computer program product, characterized in that, It includes computer program instructions that cause the computer to perform the method as claimed in any one of claims 1 to 10, 11 to 15, or 16 to 17.

Images