Multi-system authentication method, device, apparatus and storage medium

Abstract

Embodiments of the present application provide a multi-system authentication method and device, electronic equipment, computer readable storage medium and computer program product, and relate to the field of operating systems. The method comprises: calling a first system in an active state to process an identity of the electronic equipment based on a preset encryption method to obtain first data; then, obtaining second data from an authorized partition; checking whether the second data is consistent with the first data to determine an authentication result of whether the electronic equipment is correctly authorized, and sharing the authentication result when calling a second system. Embodiments of the present application implement the authentication operation in the first system to determine the authentication result of whether the electronic equipment is correctly authorized, and share the authentication result when calling the second system, which can not only realize unified authentication of multiple systems in the electronic equipment, but also call the graphical display service of the first system to process the authentication process in a friendly manner.

Description

Technical Field

[0001] This application relates to the field of operating system technology, and more specifically, to a multi-system authentication method, apparatus, electronic device, computer-readable storage medium, and computer program product. Background Technology

[0002] For mobile terminal and other electronic device operating system manufacturers, one business model is to license the operating system of electronic devices and charge licensing fees.

[0003] As business scenarios expand across various industries, mobile electronic devices and other products based on Linux container technology, operating in multiple domains and systems, have secured a place in the market. Mobile electronic devices are primarily divided into two categories of container domain systems: security domain systems for handling business operations with high security requirements, such as office work, and lifestyle domain systems for handling communication, entertainment, and other needs without high security requirements. For manufacturers, multi-domain, multi-system electronic devices only require users to purchase a system license service once to obtain authorization for each system. However, for electronic devices and other products requiring authorization, an authentication process is generally needed to confirm whether the product is correctly authorized during use. Authentication is typically a long-term, continuous process; the electronic device must be authenticated every time it starts up, and only after successful authentication can the user use the electronic device normally.

[0004] Currently, the common authentication strategy involves adding an authentication process to the system-level container support platform BaseOS. Only after successful authentication is the container creation service initiated to create the container domain system. If the system is not properly authorized, a graphical display service needs to be enabled at this stage to display an authorization failure message. However, this contradicts the fact that BaseOS only needs to focus on the creation and destruction of containers. If BaseOS provides a graphical display service solely for authentication, it represents a significant waste of system resources. Summary of the Invention

[0005] The solutions shown in the embodiments of this application are intended to solve one of the above-mentioned technical problems.

[0006] According to one aspect of the embodiments of this application, a multi-system authentication method is provided, the method comprising:

[0007] The system invokes a first active system to process the electronic device's identity data according to a preset encryption method, obtaining first data; it then retrieves second data from the authorized partition; it verifies whether the second data is consistent with the first data to determine the authentication result used to indicate whether the electronic device has been correctly authorized, and shares the authentication result when invoking the second system.

[0008] In one possible implementation, invoking the first active system includes:

[0009] A first system is created in an electronic device and set as a secure domain; at least one second system is created in the electronic device and set as a non-secure domain, wherein the secure domain and the non-secure domain are isolated from each other; the first system is set to an active state and the at least one second system is set to an inactive state.

[0010] In another possible implementation, the first active system is invoked, including:

[0011] Create at least two second systems, each of which is either a secure domain or a non-secure domain; select systems that meet the conditions from the at least two second systems based on preset configuration information, and determine the systems that meet the conditions as the first system; set the first system to an active state, and set all systems in the at least two second systems except the first system to an inactive state.

[0012] In another possible implementation, the identity data of the electronic device is processed according to a preset encryption method to obtain first data, including:

[0013] The preset identifier is used as identity data for signature processing, and the signature processing result is encrypted according to the preset key to obtain the first data.

[0014] In yet another possible implementation, the process of configuring the electronic device includes:

[0015] Create an authorized partition and perform any of the following configuration operations on the authorized partition:

[0016] Configure authorized partitions to be visible to secure domains and not visible to non-secure domains; configure authorized partitions to be visible to any domain of an electronic device.

[0017] In another possible implementation, if the verification results are consistent, the authentication result indicates that the electronic device has been correctly authorized. The method further includes:

[0018] Displays the main interface of the first system;

[0019] Among them, sharing the authentication result when calling the second system includes: if a system switching instruction is received in the main interface of the first system, the main interface of the first system is switched to the main interface of any second system.

[0020] In another possible implementation, if the verification result is inconsistent, indicating that the electronic device has not been properly authorized, the method further includes:

[0021] The first system is invoked to display authentication failure information.

[0022] According to another aspect of the embodiments of this application, a multi-system authentication apparatus is provided, the apparatus comprising:

[0023] The processing module is used to call the first system, which is in an active state, to process the identity data of the electronic device according to a preset encryption method, and obtain the first data.

[0024] The module retrieves the second data from the authorized partition.

[0025] The verification module verifies whether the second data is consistent with the first data to determine the authentication result used to indicate whether the electronic device has been properly authorized, and shares the authentication result when calling the second system.

[0026] According to another aspect of the embodiments of this application, an electronic device is provided, the electronic device including: a memory, a processor and a computer program stored in the memory, the processor executing the computer program to implement the steps of the multi-system authentication method shown in one of the above embodiments of this application.

[0027] According to another aspect of the embodiments of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the multi-system authentication method shown in one of the above embodiments of this application.

[0028] The beneficial effects of the technical solutions provided in this application are:

[0029] This application provides a multi-system authentication method, which includes: calling a first system in an active state to process the identity identifier of an electronic device based on a preset encryption method to obtain first data; then, obtaining second data from an authorization partition; verifying whether the second data is consistent with the first data to determine whether the electronic device has obtained correct authorization authentication, and sharing the authentication result when calling the second system. The method shown in this application determines whether the electronic device has obtained correct authorization authentication by performing authentication operations in the first system and sharing the authentication result when calling the second system, thereby achieving the purpose of unified authentication of multiple systems in the electronic device. Furthermore, since the first system can provide a graphical display service, if the authentication result indicates that the electronic device has not obtained correct authorization, the graphical display service of the first system can also be called to display the authentication result to the user. Attached Figure Description

[0030] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below.

[0031] Figure 1 A schematic diagram of the system architecture of an electronic device provided in this application embodiment;

[0032] Figure 2 A flowchart illustrating a multi-system authentication method provided in an embodiment of this application;

[0033] Figure 3a This is a schematic diagram of a partition structure in an electronic device provided in an embodiment of this application;

[0034] Figure 3b This is a schematic diagram of a partition structure in another electronic device provided in an embodiment of this application;

[0035] Figure 4a A schematic diagram of the structure of a multi-system authentication device provided in this application embodiment;

[0036] Figure 4b A schematic diagram of the structure of a multi-system authentication device provided in this application embodiment;

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

[0038] The embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the embodiments described below with reference to the accompanying drawings are exemplary descriptions for explaining the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions of the embodiments of this application.

[0039] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the terms “comprising” and “including” as used in embodiments of this application mean that the corresponding feature can be implemented as the presented feature, information, data, step, operation, element, and / or component, but do not exclude implementation as other features, information, data, step, operation, element, component, and / or combinations thereof supported by the art. It should be understood that when we say that an element is “connected” or “coupled” to another element, the one element can be directly connected or coupled to the other element, or it can mean that the one element and the other element establish a connection relationship through an intermediate element. Furthermore, “connected” or “coupled” as used herein can include wireless connection or wireless coupling. The term “and / or” as used herein indicates at least one of the items defined by the term; for example, “A and / or B” can be implemented as “A,” or as “B,” or as “A and B.”

[0040] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0041] The following is combined with Figure 1The system architecture of an electronic device shown illustrates a common authentication strategy.

[0042] Kernel: The kernel layer, the core module of the operating system, responsible for managing various tasks, allocating CPU time for each task, and handling communication between tasks. The kernel layer includes, but is not limited to, items such as... Figure 1 The files are shown in multiple paths.

[0043] BaseOS: The file system supporting the system and container platform, following the single-root, inverse-order structure of the Linux file system. At the BaseOS layer, the main functions implemented include managing the lifecycle of containers, such as creation and destruction, as well as switching between foreground and background containers. BaseOS includes, but is not limited to, ... Figure 1 The files are shown in multiple paths.

[0044] Container: Multiple container domain systems created by BaseOS based on configuration files, including but not limited to... Figure 1 The various systems shown. Unless otherwise specified, "container," "container domain system," and "domain" are considered synonyms. The term "system" unless otherwise specified refers to a container domain system.

[0045] The typical authentication / authorization strategy involves implementing the authentication / authorization process within the BaseOS. Regarding the authentication process, if the authentication is successful, the container creation service is started to create the container; if the authentication fails, the user is notified of the failure graphically.

[0046] However, the above strategy has the following contradictions: On the one hand, when implementing the authentication process at the BaseOS layer, if the system is not properly authorized, a graphical display service should be enabled based on the needs of the authentication process. On the other hand, the BaseOS layer mainly provides services for container creation and destruction, and does not provide a graphical display service. Therefore, if the authentication process is implemented at the BaseOS layer, it is difficult to handle problems such as authentication failure.

[0047] To address at least one of the aforementioned technical problems or areas requiring improvement in related technologies, this application proposes a multi-system authentication method, apparatus, electronic device, computer-readable storage medium, and computer program product. The multi-system authentication method described in this application determines whether the electronic device has been correctly authorized by performing an authentication operation in a first system, and shares this authentication result when calling the second system, thereby achieving unified authentication of multiple systems within the electronic device.

[0048] The technical solutions of this application and their effects are described below through several exemplary embodiments. It should be noted that the following embodiments can be referenced, borrowed from, or combined with each other. Identical terms, similar features, and similar implementation steps in different embodiments will not be repeated.

[0049] This application provides a multi-system authentication method, which is applied to an electronic device configured with at least two systems. For details of the method, please refer to [link to relevant documentation]. Figure 2 The flowchart shown indicates that the method may include steps S210 to S230.

[0050] S210, the first system, which is in an active state, is invoked to process the identity data of the electronic device according to a preset encryption method to obtain the first data.

[0051] Optionally, the electronic device includes a CPU, GPU, memory, graphics card, display screen, etc. In addition, the electronic device may include a device identifier set by the device manufacturer. Optionally, the identification data can be any one of the following: device identifier, unique identifier of the CPU, unique identifier of the GPU, unique identifier of the memory, unique identifier of the graphics card, unique identifier of the display screen, or other reasonable identifier of the electronic device. It can also be any combination of multiple of the aforementioned identifiers; this application does not impose any restrictions on this.

[0052] Alternatively, the architecture of the electronic device can be referenced. Figure 1 The diagram shows the architecture of the electronic device. The kernel can be a Linux operating system kernel, and the BaseOS can be implemented using computer programming based on its functional description.

[0053] S220, retrieves the second data from the authorized partition.

[0054] The second data is authentication data used to verify the first data.

[0055] Optionally, provided the electronic device's identity is verified, such as during the first boot after the electronic device leaves the factory, the BaseOS creates a container domain system (e.g., the first system). This container domain system initiates an authorization process and generates second data. This second data cannot be arbitrarily modified and can be used long-term.

[0056] Optionally, when the electronic device is first booted after leaving the factory, BaseOS creates a container domain system (e.g., the first system). This container domain system performs authorization operations through an authorization service. Specifically, the container domain system starts a socket listening service, waiting for the authorization tool or authorization server to exchange authorization data. If the authorization is successful, authentication data, i.e., the second data, is generated and written to the authorization partition.

[0057] Typically, the authorization process is executed only once, and after the second data is generated, the authorization process is not executed again; however, electronic devices require authentication every time they are started, and the second data is used as authentication data for a long time. In addition, the authorization process can adopt other methods with reference to existing technologies, and the embodiments of this application do not limit it.

[0058] S230, verify whether the second data is consistent with the first data to determine the authentication result used to indicate whether the electronic device has been properly authorized, and share the authentication result when calling the second system.

[0059] Specifically, different systems use different authorization methods. However, a user only needs to purchase an authorization for an electronic device once, and the manufacturer of the electronic device will then authorize all systems on that device. Therefore, if the first data matches the second data, the authentication result indicates that the electronic device has been correctly authorized; if the first data does not match the second data, the authentication result indicates that the electronic device has not been correctly authorized.

[0060] Optionally, sharing the authentication result when calling the second system may specifically include: if the authentication result indicates that the electronic device has been correctly authorized, no authentication operation is required when calling the second system; if the authentication result indicates that the electronic device has not been correctly authorized, the second system cannot be called or the call to the second system fails.

[0061] The method described in this application determines whether an electronic device has been correctly authorized by performing an authentication operation in the first system, and shares this authentication result when calling the second system, thereby achieving unified authentication across multiple systems within the electronic device. Furthermore, since any system can provide a graphical display service, if the authentication result indicates that the electronic device has not been correctly authorized, the graphical display service of the first system can also be invoked to display the authentication result to the user.

[0062] This application embodiment also provides two possible implementation methods for the process of calling the first system in S210, which will be described in detail below.

[0063] In an optional embodiment, the first system in an active state is invoked, which may specifically include steps Sa1 to Sa3 (not shown in the figure).

[0064] Sa1 creates a first system in the electronic device and sets the first system as a security domain.

[0065] Specifically, the first system is created by the container creation service started by BaseOS.

[0066] Optionally, the container creation service can also set up multiple partitions for the created system during system creation. These partitions include private partitions and public partitions. Private partitions are accessed exclusively by the corresponding system, while public partitions are accessible to every system. It should be noted that the process of creating a system using BaseOS can refer to existing technologies, and this application does not impose any limitations on it.

[0067] Sa2, creating at least one second system in an electronic device and setting the second system as a non-security domain, wherein the security domain and the non-security domain are isolated from each other.

[0068] Specifically, a container creation service is started in BaseOS to create at least one secondary system.

[0069] Optionally, operations with higher security requirements can be performed in the secure domain, such as personalizing the functions of electronic devices or updating system login passwords. Operations without high security requirements can be performed in the non-secure domain, such as video playback and game interaction.

[0070] Sa3, wherein the first system is set to be in an active state and the at least one second system is set to be in an inactive state.

[0071] Specifically, setting the first system to an active state indicates that the first system is in the foreground of the electronic device; correspondingly, setting the second system to an inactive state indicates that the second system is in the background.

[0072] In one possible implementation, configuring the electronic device is also included. This configuration process includes:

[0073] Create an authorized partition and perform any of the following configuration operations on the authorized partition: configure the authorized partition to be visible to security domains and not visible to non-security domains.

[0074] This can be understood as the authorized partition being a private partition of the security domain, visible only to the security domain. Optionally, the security domain can access the authorized partition and perform read operations within it.

[0075] In response to this optional embodiment, this application also provides a scenario example, see details below. Figure 3a The diagram shows a partition structure in an electronic device.

[0076] In this example, the electronic device includes at least two systems: a security domain LinuxOS and a non-security domain AndroidOS. The Linux and Android systems each include at least six partitions, from partition 1 to partition 6. Partitions 1 through 6 can be, in order: Loader (boot partition), Parameter (boot parameter partition), Uboot (partition storing the boot loader), Boot (partition containing boot files and the kernel), Recovery (recovery partition), and System (system partition). Partitions 1 through 6 are private partitions for their respective systems. The non-security domain can be the life domain, used for operations with low security requirements, such as playing videos, music, or interactive games.

[0077] In this example, an authorization partition is also set up. The authorization partition is set to be visible to the security domain but not to the non-security domain.

[0078] In this example, after the electronic device is powered on, the security domain and the non-security domain are isolated from each other. Only the visible partition of the security domain includes the authorization partition.

[0079] In another alternative embodiment, the first system, which is in an active state, is invoked, including steps Sb1 to Sb3.

[0080] Sb1, create at least two second systems.

[0081] Specifically, at least two secondary systems are created by BaseOS. Optionally, either a secondary system can be a secure domain or a non-secure domain.

[0082] Sb2, based on preset configuration information, selects a system that meets the conditions from at least two second systems, and determines the system that meets the conditions as the first system;

[0083] Optionally, the preset configuration information includes the identity identifier of the first system called when the electronic device is started, and the system corresponding to the identity identifier is selected from at least two second systems based on the identity identifier and determined as the first system.

[0084] Sb3, respectively setting the first system to an active state, and setting all systems in the at least two second systems except the first system to an inactive state.

[0085] Specifically, setting the first system pair to an active state indicates that the first system is in the foreground of the electronic device.

[0086] In one possible implementation, configuring the electronic device is also included. This configuration process includes:

[0087] Create an authorized partition and perform any of the following configuration operations on the authorized partition: Configure the authorized partition to be visible to any domain of the electronic device.

[0088] Optionally, the authorized partition can be visible as a public partition to any domain of the electronic device. Optionally, any domain can access the authorized partition and perform read operations within it.

[0089] For this optional embodiment, this application also provides a scenario example, see details below. Figure 3b The diagram shows a partition structure in another electronic device.

[0090] In this example, the electronic device includes at least two systems: a security domain LinuxOS and a non-security domain AndroidOS. The Linux and Android systems each include at least six partitions, from partition 1 to partition 6. Partitions 1 through 6 can be, in order: Loader (boot partition), Parameter (boot parameter partition), Uboot (partition storing the boot loader), Boot (partition containing boot files and the kernel), Recovery (recovery partition), and System (system partition). Partitions 1 through 6 are private partitions for their respective systems. The non-security domain can be the life domain, used for operations with low security requirements, such as playing videos, music, or interactive games.

[0091] In this example, the electronic device includes at least two operating systems: a security domain LinuxOS and a non-security domain AndroidOS. Additionally, an authorization partition is configured to be visible to both the security and non-security domains.

[0092] In this example, after the electronic device is powered on, the secure and non-secure domains are isolated from each other. The visible partitions in both the secure and non-secure domains include authorized partitions.

[0093] In this example, any active system can access the authorized partition and perform read operations on it.

[0094] Regarding the process of obtaining the first data described above, this application embodiment also provides a possible implementation method, which involves processing the identity data of the electronic device according to a preset encryption method to obtain the first data, specifically including:

[0095] The preset identifier is used as identity data for signature processing, and the signature processing result is encrypted according to the preset key to obtain the first data.

[0096] Optionally, each time the electronic device is powered on, it uses a preset identifier as identity data for signature processing, and further encrypts the signature result according to a preset key to obtain the first data. The second data is then verified to ensure consistency with the first data. If the first data matches the second data stored in the authorization partition, the device has been correctly authorized; otherwise, the device has not been correctly authorized.

[0097] It should be noted that both the signature and encryption processes can refer to existing technologies.

[0098] Regarding the consistency of verification results, this application also provides corresponding implementation methods, and the verification results will be described in detail below.

[0099] In an optional implementation, if the verification results are consistent, the authentication result indicates that the first system has been correctly authorized. The method further includes:

[0100] Displays the main interface of the first system.

[0101] Optionally, the authentication result can be shared when the second system is invoked, including:

[0102] If a system switching command is received in the main interface of the first system, switch the main interface of the first system to the main interface of any second system.

[0103] Optionally, the main interface can be the desktop of the corresponding system, or any interface of the corresponding system, such as the login interface of the first system.

[0104] In an optional implementation, if the verification result is inconsistent, indicating that the electronic device has not been properly authorized, the method further includes:

[0105] The first system is invoked to display authentication failure information.

[0106] Optionally, a pop-up "prompt box" can be displayed, showing messages such as "Authentication failed" or "Your device is not properly authorized".

[0107] Since the first data is determined based on the electronic device's identity identifier, which can be one or more of the various reasonable identifiers shown in the foregoing embodiments, such as a device identifier, a unique identifier for the CPU, a unique identifier for the GPU, a unique identifier for the memory, a unique identifier for the graphics card, or a unique identifier for the display screen, if any of the aforementioned reasonable identifiers determining the identity identifier is updated—for example, if the user performs an operation such as updating the CPU, graphics card, or display screen of the electronic device—the corresponding unique identifiers for the CPU, graphics card, and display screen will be updated. Furthermore, the electronic device's identity identifier is indirectly updated as well. Performing an authentication operation based on the first data obtained from the updated identity identifier will result in authentication failure. Therefore, the electronic device can also invoke the first system to initiate an authorization service to perform an authorization operation, thereby updating the second data in the authorization partition.

[0108] This application embodiment also provides a multi-system authentication device 400, which is applied to an electronic device. The device 400 includes a processing module 410, an acquisition module 420, and a verification module 430, specifically as follows... Figure 4a As shown.

[0109] The processing module 410 is used to call the first system in an active state to process the identity data of the electronic device according to a preset encryption method to obtain the first data.

[0110] Module 420 retrieves the second data from the authorized partition.

[0111] The verification module 430 verifies whether the second data is consistent with the first data to determine the authentication result used to indicate whether the electronic device has been properly authorized, and shares the authentication result when calling the second system.

[0112] In one possible implementation, the processing module 410, in the first system where the call is active, specifically performs the following:

[0113] A first system is created in an electronic device and set as a secure domain; at least one second system is created in the electronic device and set as a non-secure domain, wherein the secure domain and the non-secure domain are isolated from each other; the first system is set to an active state and the at least one second system is set to an inactive state.

[0114] In one possible implementation, the processing module 410, when calling the first system in an active state, can also be specifically used for:

[0115] Create at least two second systems, each of which is either a secure domain or a non-secure domain; select systems that meet the conditions from the at least two second systems based on preset configuration information, and determine the systems that meet the conditions as the first system; set the first system to an active state, and set all systems in the at least two second systems except the first system to an inactive state.

[0116] In one possible implementation, the processing module 410, in processing the electronic device's identity data according to a preset encryption method to obtain the first data, specifically performs the following:

[0117] The identity data is signed according to a preset identifier, and the signing result is encrypted according to a preset key to obtain the first data; wherein, if the verification result is consistent, the second data is obtained according to the preset identifier and the preset key.

[0118] In one possible implementation, the processing module 410, in configuring the electronic device prior to the start command, can also be used for:

[0119] Create an authorized partition and perform any of the following configuration operations on the authorized partition:

[0120] Configure authorized partitions to be visible to secure domains and not visible to non-secure domains; configure authorized partitions to be visible to any domain of an electronic device.

[0121] In one possible implementation, the device 400 may further include a display module 440, specifically as follows: Figure 4b As shown. If the verification result is consistent, the authentication result indicates that the electronic device has been correctly authorized, and the display module 440 can be used for:

[0122] Displays the main interface of the first system.

[0123] Among them, sharing the authentication result when calling the second system includes: if a system switching instruction is received in the main interface of the first system, the main interface of the first system is switched to the main interface of any second system.

[0124] In one possible implementation, if the verification result is inconsistent, indicating that the electronic device has not been properly authorized, the display module 440 can also be used for:

[0125] The first system is invoked to display authentication failure information.

[0126] The apparatus in this application embodiment can execute the method provided in this application embodiment, and the implementation principle is similar. The actions performed by each module in the apparatus of each embodiment of this application correspond to the steps in the method of each embodiment of this application. For detailed functional descriptions of each module of the apparatus, please refer to the descriptions in the corresponding methods shown above, which will not be repeated here.

[0127] This application provides an electronic device, including a memory, a processor, and a computer program stored in the memory. The processor executes the computer program to implement the steps of the method, which, compared with related technologies, can achieve: determining whether the electronic device has obtained a correct authorization by performing an authentication operation on a first system, and sharing the authentication result when calling a second system, thereby realizing unified authentication of multiple systems in the electronic device.

[0128] In one alternative embodiment, an electronic device is provided, such as Figure 5 As shown, Figure 5 The illustrated electronic device 5000 includes a processor 5001 and a memory 5003. The processor 5001 and the memory 5003 are connected, for example, via a bus 5002. Optionally, the electronic device 5000 may further include a transceiver 5004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 5004 is not limited to one type, and the structure of the electronic device 5000 does not constitute a limitation on the embodiments of this application.

[0129] Processor 5001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 5001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0130] Bus 5002 may include a path for transmitting information between the aforementioned components. Bus 5002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 5002 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 5The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0131] The memory 5003 may be ROM (Read Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media, other magnetic storage devices, or any other medium capable of carrying or storing computer programs and capable of being read by a computer, without limitation herein.

[0132] The memory 5003 is used to store computer programs that execute the embodiments of this application, and its execution is controlled by the processor 5001. The processor 5001 is used to execute the computer programs stored in the memory 5003 to implement the steps shown in the foregoing method embodiments.

[0133] Electronic devices include, but are not limited to, computers.

[0134] This application provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it can implement the steps and corresponding content of the aforementioned method embodiments.

[0135] This application also provides a computer program product, including a computer program that, when executed by a processor, can implement the steps and corresponding content of the aforementioned method embodiments.

[0136] The terms "first," "second," "third," "fourth," "1," "2," etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in a sequence other than that shown in the figures or text.

[0137] It should be understood that although arrows indicate various operation steps in the flowcharts of this application's embodiments, the order in which these steps are implemented is not limited to the order indicated by the arrows. Unless explicitly stated herein, in some implementation scenarios of this application's embodiments, the implementation steps in each flowchart can be executed in other orders as required. Furthermore, some or all steps in each flowchart, based on the actual implementation scenario, may include multiple sub-steps or multiple stages. Some or all of these sub-steps or stages can be executed at the same time, and each sub-step or stage can also be executed at different times. In scenarios where execution times differ, the execution order of these sub-steps or stages can be flexibly configured according to requirements, and this application's embodiments do not limit this.

[0138] The above description is only an optional implementation method for some implementation scenarios of this application. It should be noted that for those skilled in the art, other similar implementation methods based on the technical concept of this application without departing from the technical concept of this application also fall within the protection scope of the embodiments of this application.

Claims

1. A multi-system authentication method, characterized by, The method comprises: calling a first system in an active state to process identity data of an electronic device according to a preset encryption mode to obtain first data; the first system is a container domain system created by BaseOS as a secure domain; obtaining second data from an authorized partition only visible to the secure domain; checking whether the second data is consistent with the first data to determine an authentication result for indicating whether the electronic device is correctly authorized, and sharing the authentication result when a second system is called; the second system is a container domain system created by BaseOS as a non-secure domain; wherein the first system provides a graphical display service, and the graphical display service is called to show the authentication result to a user when authentication fails.

2. The method of claim 1, wherein, The calling of the first system in the active state comprises: creating the first system in the electronic device and setting the first system as a secure domain; creating at least one second system in the electronic device and setting the second system as a non-secure domain, wherein the secure domain and the non-secure domain are isolated from each other; respectively setting the first system in an active state and the at least one second system in a non-active state.

3. The method of claim 1, wherein, The calling of the first system in the active state comprises: creating at least two second systems, each of which is a secure domain or a non-secure domain; filtering a system meeting a condition from the at least two second systems according to preset configuration information, and determining the system meeting the condition as the first system; respectively setting the first system in an active state and all systems in the at least two second systems except the first system in a non-active state.

4. The method of claim 1, wherein, The processing of the identity data of the electronic device according to the preset encryption mode to obtain the first data comprises: signing the preset identity as the identity data, and encrypting a signing result according to a preset key to obtain the first data.

5. The method according to any one of claims 2-4, characterized in that, The process of configuring the electronic device comprises: creating the authorized partition, and performing any one of the following configuration operations on the authorized partition: configuring the authorized partition to be visible to the secure domain and invisible to the non-secure domain; configuring the authorized partition to be visible to any domain of the electronic device.

6. The method according to any one of claims 2-4, characterized in that, If the checking result is consistent, the authentication result indicates that the electronic device has been correctly authorized, and the method further comprises: displaying a main interface of the first system; wherein the sharing of the authentication result when the second system is called comprises: if an instruction of switching systems is received in the main interface of the first system, switching the main interface of the first system to a main interface of any second system.

7. The method according to any one of claims 2-4, characterized in that, If the checking result is inconsistent, the authentication result indicates that the electronic device has not been correctly authorized, and the method further comprises: calling the first system to display authentication failure information.

8. A multi-system authentication apparatus, characterized by comprising: comprise: a processing module configured to call a first system in an active state to process identity data of an electronic device according to a preset encryption mode to obtain first data; the first system is a container domain system created by BaseOS as a secure domain; an obtaining module configured to obtain second data from an authorized partition only visible to the secure domain; A verification module is configured to verify whether the second data is consistent with the first data to determine an authentication result indicating whether the electronic device is properly authorized, and share the authentication result when invoking a second system, which is a container domain system created by the BaseOS as a non-secure domain. The first system provides a graphical display service, and the graphical display service is invoked to show the authentication result to a user when the authentication fails.

9. An electronic device comprising a memory, a processor, and a computer program stored on the memory, wherein the computer program comprises instructions that, when executed by the processor, cause the electronic device to perform the method of any one of claims 1-8. The processor executes the computer program to implement the steps of the method of any one of claims 1-7.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the method of any one of claims 1-7.

Images