Unified identity recognition method and electronic equipment

Abstract

The invention relates to the technical field of virtualization frameworks, in particular to a unified identity recognition method and electronic equipment. The unified identity recognition method is applied to an Android system and comprises the steps that after a first upper-layer application logs in successfully, an identity token is acquired from a login background; the first upper layer application encrypts the identity token to obtain an encrypted identity token; the first upper-layer application calls the secure virtual machine, and the secure virtual machine sends the encrypted identity token to the trusted execution environment after verifying the identity of the first upper-layer application; the trusted execution environment decrypts the encrypted identity token to obtain the identity token and stores the identity token in a shared storage area; the second upper-layer application calls the secure virtual machine, and after the secure virtual machine verifies the identity of the second upper-layer application, the identity token is obtained from the shared storage area and returned to the second upper-layer application to complete login. And safe sharing of identity information is ensured. And the overall security and processing efficiency of identity recognition under the Android system are improved.

Description

A unified identity recognition method and electronic device Technical Field

[0001] This invention relates to the field of virtualization framework technology, and in particular to a unified identity recognition method and electronic device. Background Technology

[0002] The unified account in related technologies either does not provide an account sharing mechanism for upper-layer applications, or the information sharing between applications in a rich execution environment (REE) has weak protection capabilities for identity tokens. Summary of the Invention

[0003] The technical problem to be solved by this invention is to provide a unified identity recognition method to achieve secure sharing of upper-layer application accounts.

[0004] To address the aforementioned technical problems, the present invention provides a unified identity recognition method, characterized in that it is applied to an Android system, wherein a rich execution environment, a secure virtual machine, and a trusted execution environment run on the Android system, and at least two upper-layer applications run on the rich execution environment. The method includes: after a first upper-layer application successfully logs in, it obtains an identity token from the login backend; the first upper-layer application encrypts the identity token to obtain an encrypted identity token; the first upper-layer application calls the secure virtual machine, and after the secure virtual machine verifies the identity of the first upper-layer application, it sends the encrypted identity token to the trusted execution environment; the trusted execution environment decrypts the encrypted identity token to obtain an identity token and stores it in a shared storage area; the second upper-layer application calls the secure virtual machine, and after the secure virtual machine verifies the identity of the second upper-layer application, it obtains the identity token from the shared storage area and returns it to the second upper-layer application to complete the login.

[0005] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is: an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the unified identity recognition method described in claim 1.

[0006] The beneficial effects of this invention are as follows: This application runs a secure virtual machine, at least two upper-layer applications, and a trusted execution environment on an Android system. After the first upper-layer application successfully logs in, it obtains an identity token from the login backend and encrypts it to obtain an encrypted identity token. The first upper-layer application calls the secure virtual machine, which verifies the identity of the first upper-layer application and then sends the encrypted identity token to the trusted execution environment. Encryption of the identity token ensures secure transmission. The trusted execution environment decrypts the encrypted identity token, obtains the identity token, and stores it in a shared storage area. The secure isolation features of the trusted execution environment ensure the confidentiality of the stored identity token. The second upper-layer application calls the secure virtual machine to obtain an identity token. After the secure virtual machine verifies the identity of the second upper-layer application, it retrieves the identity token from the shared storage area and returns it to the second upper-layer application to complete the login. The encrypted identity token is decrypted and stored in the shared storage area, allowing the second upper-layer application to obtain the identity token through the shared storage area. This enables the second application to obtain the identity token directly from the shared storage area without logging in, ensuring secure sharing of identity information. This improves the overall security and processing efficiency of identity recognition under the Android system. Attached Figure Description

[0007] Figure 1 is a flowchart of a unified identity recognition method provided in an embodiment of the present invention; Figure 2 is a structural schematic diagram of an electronic device provided in an embodiment of the present invention; Figure 3 is a system architecture diagram of a unified identity recognition method provided in an embodiment of the present invention. Detailed Implementation

[0008] To make the technical problems, technical solutions, and beneficial effects to be solved by this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this application.

[0009] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0010] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0011] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0012] The following are some related terms used in this invention: AVF: Android Virtualization Framework (AVF) provides a secure and private execution environment for executing code. AVF is well-suited for security-oriented use cases that require a higher level of security, or even formally validated isolation guarantees, than those provided by the Android application sandbox.

[0013] pVM: An untrusted, isolated execution environment (client) that runs alongside the main Android operating system (host). pVM provides an isolated execution environment, enabling parts of an application to run with greater confidentiality and integrity than a regular Android environment.

[0014] Identity Token: An identity token is a random string or encrypted block of data used for authentication, secure access, or authorization control. It represents authorization information for a user, device, or session. The user provides credentials (such as username and password) for authentication, and after the server verifies the identity, it generates an identity token and returns it to the user.

[0015] REE: Rich Execution Environment. The primary operating system environment of the device, in this application, refers to the Android system.

[0016] Trusted Execution Environment (REE): A secure zone created through hardware isolation technology that coexists with the REE. In this application, it refers to a Trusted system.

[0017] Unified Identity (TA): This refers to Trusted Applications, which divide account information into multiple account ranges. It stores shared account information across multiple applications. Each account range includes: 1. An Account Range ID, serving as the identifier for this range; 2. An Identity Token Pool, recording the account identity tokens stored in this range; 3. An Authorized Application List, recording the list of applications allowed to access this account range; and 4. An Account Range Manager, recording the administrator information allowed to manage this range. Administrator information can include app information, fingerprints, facial recognition, or other biometric data, used to verify the legitimacy of the operator when managing the application list.

[0018] Among related technologies, there are several types of multi-application account sharing solutions. One type is based on account sharing between system applications, such as Huawei's Settings, Music, and Video applications sharing login status. When one application logs in, other applications avoid entering their account login information upon startup. This provides an account sharing mechanism for the system's own applications from a customized system, and other third-party applications cannot share this mechanism. Another type involves third-party applications using the cross-application communication mechanism provided by the Android system to transmit and share logged-in account data across applications. This type of solution is more complex to implement in multiple applications and has insufficient security. It may be vulnerable to interception or alteration of shared account information due to attacks on the REE environment.

[0019] Systems in related technologies, such as Android, often provide biometric interfaces for upper-layer applications, such as face recognition, fingerprint recognition, and iris recognition. Through these interfaces, upper-layer applications can directly call or use pre-packaged SDKs to forward calls to the system's basic biometric interfaces for authentication. However, existing biometric technologies essentially trigger biometric information collection, input, and authentication results within a REE (Remote Access Provider) environment. Information collection and input can be intercepted due to attacks on the REE environment, and results can be obtained through deception. Unified accounts in related technologies either lack an account-sharing mechanism for upper-layer applications or suffer from weak identity token protection during information sharing between applications at the REE layer.

[0020] The following describes a unified identity recognition method of the present invention, applied to an Android system. The Android system runs a rich execution environment, a secure virtual machine, and a trusted execution environment. At least two upper-layer applications run on the rich execution environment. Referring to Figure 1, the method includes steps 110 to 150: Step 110: After successful login, the first upper-layer application obtains an identity token from the login backend; Step 120: The first upper-layer application encrypts the identity token to obtain an encrypted identity token; Step 130: The first upper-layer application calls the secure virtual machine. After verifying the identity of the first upper-layer application, the secure virtual machine sends the encrypted identity token to the trusted execution environment; Step 140: The trusted execution environment decrypts the encrypted identity token to obtain the identity token. The token is stored in a shared storage area; Step 150: The second upper-layer application calls the secure virtual machine. After verifying the identity of the second upper-layer application, the secure virtual machine retrieves the identity token from the shared storage area and returns it to the second upper-layer application to complete the login. As described above, this embodiment runs a secure virtual machine, at least two upper-layer applications, and a trusted execution environment on the Android system. After the first upper-layer application successfully logs in, it retrieves the identity token from the login backend and encrypts it to obtain an encrypted identity token. The first upper-layer application calls the secure virtual machine. After verifying the identity of the first upper-layer application, the secure virtual machine sends the encrypted identity token to the trusted execution environment. Encrypting the identity token ensures its secure transmission. The trusted execution environment decrypts the encrypted identity token and stores it in the shared storage area. The security isolation feature of the trusted execution environment ensures the confidentiality of the stored identity token. The second upper-layer application calls the secure virtual machine to obtain the identity token. After verifying the identity of the second upper-layer application, the secure virtual machine retrieves the identity token from the shared storage area and returns it to the second upper-layer application to complete the login. The encrypted identity token is decrypted and stored in the shared storage area, enabling the second upper-layer application to obtain the identity token through the shared storage area. This allows second applications to obtain identity tokens directly from the shared storage area without needing to log in, ensuring secure sharing of identity information. It improves the overall security and processing efficiency of identity recognition on the Android system.

[0021] In one embodiment of this application, after the first upper-layer application successfully logs in and obtains the identity token from the login backend, step 110 further includes: Step 210: The first upper-layer application sends a virtual machine authentication request to the secure virtual machine through the rich execution environment; Step 220: The secure virtual machine uses its private key to digitally sign the virtual machine authentication request, generating a digital signature; Step 230: The secure virtual machine combines the virtual machine authentication request and the digital signature to generate an identity credential and sends it to the rich execution environment; Step 240: After receiving the identity credential, the rich execution environment uses the secure virtual machine's public key to verify the legality of the digital signature in the identity credential. If it is legal, it determines whether the virtual machine authentication request in the identity credential is the same as the generated virtual machine authentication request. If so, it sends the public key to the first upper-layer application. As can be seen from the above description, this embodiment achieves virtual machine identity authentication through digital signature and two-way verification mechanism. Thus, this embodiment ensures the unforgeability and transmission integrity of the virtual machine identity credential through the cryptographic pairing operation of private key signing and public key verification, and achieves dual verification of identity authenticity through request content comparison, thereby effectively preventing man-in-the-middle attacks and identity impersonation risks while establishing cross-domain communication trust relationships.

[0022] In one embodiment of this application, the method further includes: Step 310: The secure virtual machine obtains the timestamp of the virtual machine authentication request; Step 320: The secure virtual machine generates a random number; Step 330: The secure virtual machine signs the unique identifier of the secure virtual machine, the version information of the secure virtual machine, the virtual machine authentication request, the timestamp, and the random number, combines them to obtain an identity credential, and sends it to the rich execution environment; Step 340: After receiving the identity credential, the rich execution environment uses the public key of the secure virtual machine to verify the digital signature in the identity credential. If the verification is successful, it obtains the virtual machine authentication request, the timestamp, and the random number in the identity credential; Step 350: The rich execution environment verifies whether the virtual machine authentication request in the identity credential is consistent with the generated virtual machine authentication request, and verifies the legality of the version information, the timestamp, and the random number. If all verifications are successful, it sends the public key to the first upper-layer application; wherein, the unique identifier of the virtual machine includes the unique identifier of the pVM (such as the hash value of the virtual machine public key), and the version information of the virtual machine includes the version information of the Microdroid system. Specifically, the verification success criteria are: the digital signature content is consistent with the request content; the public key of the virtual machine has not been tampered with (verified through the previous secure boot chain); and the timestamp is within the valid range. If the verification is successful, the verification result and the virtual machine's public key are returned to the upper-layer application.

[0023] As described above, this embodiment encrypts the authentication request using a digital signature mechanism and completes the verification using an asymmetric key system. Therefore, this embodiment achieves tamper-proof protection of virtual machine identity credentials through a public-private key pairing verification mechanism. This ensures the integrity and authenticity of data transmission and effectively prevents replay attacks through the combination of timestamps and random numbers, thus improving the security level of identity authentication and establishing a trusted data foundation for subsequent token storage operations. This embodiment introduces multi-dimensional verification logic, which strengthens the traceability of identity sources, ensuring that the system is running the expected version. It also prevents replay attacks through timestamp validity verification and prevents prediction attacks through random numbers. While ensuring the immutability of the identity authentication process, it enhances the defense capabilities against virtual machine identity forgery and session replay attacks.

[0024] In one embodiment of this application, step 140 involves the Trusted Execution Environment (TEE) decrypting the encrypted identity token to obtain an identity token and storing it in a shared storage area. This includes: Step 410: The TEE queries the target account range corresponding to the first upper-layer application; Step 420: The TEE decrypts the encrypted identity token using the public key of the secure virtual machine to obtain an identity token and stores it in the shared storage area of ​​the target account range. Specifically, the Unified Identity (TA) in the TEE only receives requests from the Unified Identity Service on the virtual machine. Upon receiving a request, it retrieves the existing list of account range applications, queries which account ranges the application requesting to write or update the identity token belongs to, decrypts the identity token content using the virtual machine's private key, stores it in the shared storage area of ​​these account ranges, and returns the result. Applications within the same account range can share account login information and identity tokens.

[0025] As described above, this embodiment achieves secure distribution of identity tokens through account-wide targeted storage and key decryption mechanisms. Thus, by limiting the unified identity identifier (TA) to respond only to requests from the virtual machine service, and combining account-wide retrieval with virtual machine private key decryption, this embodiment achieves isolated storage of identity tokens within a specific account scope, while ensuring the confidentiality of token transmission through key pairing encryption and decryption mechanisms. This ensures both controllable access to identity information and data security while supporting shared login status across multiple applications.

[0026] In one embodiment of this application, the method further includes: Step 510: The first upper-layer application sends an identity token saving request to the security virtual machine, the identity token saving request including an encrypted identity token; Step 520: The security virtual machine performs permission verification on the identity token saving request, and if the verification is successful, it sends the identity token saving request to the trusted execution environment; Specifically, after receiving the request, the unified identity service on the virtual machine verifies whether the application has permission to call the interface through the permission management module. If the permission verification is successful, the unified identity service on the virtual machine applies to the unified identity TA of the trusted execution environment to save or update the identity token.

[0027] As described above, this embodiment sends a request to the unified identity recognition service through the upper-layer application and triggers a trusted execution environment storage operation after authorization verification. Thus, this embodiment achieves access control for interface calls through a layered verification mechanism, ensuring that only legitimate applications can initiate sensitive operations. Furthermore, the separation of the authorization management module from the business logic enhances the system's security isolation, thereby maintaining the integrity of the identity management process while improving the ability to protect against unauthorized access.

[0028] In one embodiment of this application, the method further includes: Step 610: The shared application registration request initiated by the first upper-layer application is transmitted to the secure virtual machine through the rich execution environment. The shared application registration request includes a registration identifier. Specifically, the upper-layer application that needs to share accounts calls the account sharing application registration API in the unified identity service of the REE, and passes in a specified account range identifier or the APP package name of the shared account as the registration identifier. When the unified identity service on the virtual machine receives the request initiated by the upper-layer application, it starts the pVM through the pVM management module and establishes a communication channel between the unified identity service on the Android system and the pVM through the vSock and Binder mechanisms of AVF. The starting of the pVM and the establishment of the communication channel utilize the communication mechanism natively provided by AVF. The unified identity service (on the REE) forwards the request to the unified identity service (on the pVM) through the aforementioned secure channel.

[0029] Step 620: The secure virtual machine (pVM) sends an authentication request corresponding to the shared application registration request to the trusted execution environment (pVM). The authentication request includes the signing certificate corresponding to the first upper-layer application. Specifically, a secure channel is established between the pVM and the trusted execution environment (pVM) through the communication mechanism between the Android system and the Trusted system. Through this secure channel, the pVM and pVM can transmit information and negotiate session keys. After key negotiation, data from the unified identity service on the pVM side and the pVM side can be transmitted encrypted using the session key.

[0030] Step 630: The Trusted Execution Environment (TEE) compares the signing certificate with the administrator signing certificate corresponding to the pre-configured registration identifier in the TEE. If they match, the TEE sends the application identity of the first upper-layer application to the secure virtual machine, indicating that the application identity is the administrator identity corresponding to the registration identifier. Specifically, if the application identity in the authentication request is the account scope administrator corresponding to the target account scope identifier, the TEE's Unified Identity Authentication (TA) pre-configures the account scope administrator's signing certificate. After receiving the application authentication request, the TEE's TA compares the signing certificate in the application signature information with the pre-configured account scope administrator's signing certificate. If they match, the application is the administrator application corresponding to the target account scope identifier.

[0031] Step 640: When the secure virtual machine receives the administrator's identity, it verifies the calling permissions of the first upper-layer application. If the verification is successful, it sends an administrator application joining request to the trusted execution environment. The administrator application joining request includes a registration identifier. Step 650: The trusted execution environment adds the first upper-layer application to the authorized application list corresponding to the registration identifier and identifies the first upper-layer application as the administrator application corresponding to the registration identifier.

[0032] As described above, this embodiment establishes a dual-security channel architecture and implements an account-scope-based certificate verification mechanism. Therefore, this embodiment achieves cross-security domain identity request transmission through a communication path from the rich execution environment to the secure virtual machine and then to the trusted execution environment. This ensures end-to-end protection of sensitive data during transmission and controls the application authorization scope through a pre-built certificate comparison mechanism. Thus, while maintaining multi-level system isolation, it effectively improves the security of account sharing. Flexible management of account scope is achieved through dynamic query and interactive authorization mechanisms.

[0033] In one embodiment of this application, the method further includes: Step 710: The Trusted Execution Environment (TEE) compares the signing certificate with the administrator signing certificate corresponding to the pre-set registration identifier in the TEE. If they do not match, the TEE sends the application identity of the first upper-layer application as the non-administrator identity corresponding to the registration identifier to the secure virtual machine. Step 720: Upon receiving the non-administrator identity, the secure virtual machine verifies the calling permissions of the first upper-layer application. If the verification is successful, it sends a normal application join request to the TEE, which includes the registration identifier. Step 730: The TEE adds the first upper-layer application to the normal application list corresponding to the registration identifier. Specifically, if the registration identifier is an application package name, the unified identity service on the virtual machine queries the unified identity TA in the TEE to see if the application package name is already in the authorized application list corresponding to the target account scope identifier. If the queried package name is in the authorized application list, the corresponding target account scope identifier list is returned, and an account scope identifier list selection interface pops up, prompting the user to select whether to allow account-shared application registration and which account scope identifier to register to. If the user selects an account scope identifier, the unified identity management module requests the unified identity TA to add the upper-layer application to the corresponding authorized application list.

[0034] If the queried package name is not in the authorized application list corresponding to the target account scope, a prompt page will pop up, indicating that the application for the queried shared account is not registered, and asking whether to continue account sharing. If the user chooses to continue, the virtual machine unified identity service will request the unified identity TA of the trusted execution environment to create a new account scope, add the application that applied for registration to the authorized application list corresponding to the newly created account scope, and return the account scope identifier.

[0035] If neither the account scope identifier nor the application package name for the shared account is passed during registration, the Unified Identity Management module will display the existing account scope identifier, prompting the user to choose to add the application to an existing account scope for account sharing, or to create a new account scope. Based on the user's choice, the application will be added to the selected account scope or a new account scope will be created to add the registered application. This means that the application is added to the specified authorized application list through the user's high-privilege operations. These high-privilege operations include user authentication via system unlock password input or biometric recognition (such as face, fingerprint, or iris scan).

[0036] As described above, this embodiment manages application account scope through a dynamic authorization mechanism and user interaction process. Thus, through a multi-level judgment process involving package name query, authorization list verification, and user selection interface, this embodiment not only achieves permission control over adding applications to account scopes but also adapts to different sharing needs by creating or selecting existing account scopes. User participation in decision-making ensures the autonomy of account scope management and system scalability. It also enables updating the authorized application list and registering applications to account scope identifiers, ensuring the authorization security of account sharing operations and allowing for flexible and dynamic updates of the authorized application list.

[0037] In one embodiment of this application, in step 150, the second upper-layer application calls the security virtual machine. After the security virtual machine verifies the identity of the second upper-layer application, it obtains an identity token from the shared storage area and returns it to the second upper-layer application to complete the login. This includes: Step 810: The second upper-layer application sends a request to the security virtual machine to obtain an identity token; Step 820: The security virtual machine verifies the permissions of the second upper-layer application. After successful verification, it sends a request to the trusted execution environment to obtain an identity token. Specifically, after receiving the request, the unified identity recognition service (pVM) verifies whether the application has the permission to call the interface through the permission management module. If the permission verification is successful, it applies to the unified identity recognition TA to obtain a shareable identity token for the application.

[0038] Step 830: The Trusted Execution Environment (TA) queries the target account range corresponding to the second upper-layer application; Step 840: The TA obtains the shared storage area corresponding to the target account range; Step 850: The second upper-layer application obtains the first identity token from the shared storage area through the secure virtual machine; Step 860: The second upper-layer application decrypts the first identity token to obtain the second identity token and completes the login; Specifically, the Unified Identity Provider (TA) queries the target account range of the application and the corresponding authorized application list, and obtains the identity token stored in the shared storage area for the corresponding account range. The queried account range identifier and the first decrypted identity token are returned to the virtual machine and then sent back to the upper-layer application. The identity token is encrypted using a protection password set by the account range administrator. If no password is set, the account range identifier is used as the default password for encryption. The second upper-layer application decrypts the first decrypted identity token to obtain the second identity token, and then verifies the identity token through the backend to complete the login.

[0039] As described above, this embodiment achieves secure data access by establishing a layered verification and token acquisition mechanism. Thus, this embodiment ensures that only authorized applications can trigger the token acquisition process through the collaborative operation of application permission verification, account scope association query and token layered decryption. It also ensures data isolation through the mapping between account scope and shared storage area, so that multiple applications can share accounts securely without having to log in repeatedly.

[0040] In one embodiment of this application, step 150, in which the second upper-layer application calls the secure virtual machine, includes: step 910: the second upper-layer application sends a request to the rich execution environment to obtain an identity token; step 920: the rich execution environment initiates the establishment of a secure channel between the rich execution environment and the secure virtual machine; step 930: the rich execution environment sends the request to obtain an identity token to the secure virtual machine through the secure channel. As can be seen from the above description, in this embodiment, the upper-layer application can also send a request to obtain a decrypted identity token through the rich execution environment. By establishing a dedicated secure channel between the rich execution environment and the virtual machine, the token request transmission is realized. In this embodiment, through the isolated communication path of the secure channel, the token acquisition request is protected from unauthorized access or tampering during transmission, and the token acquisition can be achieved through the rich execution environment, thus improving the convenience of token acquisition.

[0041] Referring to Figure 3, the above-mentioned unified identity recognition method is applied to a real-world scenario, including steps a to o: Step a: Running MicroDroid OS (corresponding to the secure virtual machine pVM), the first upper-layer application, and the Trusted system (corresponding to the trusted execution environment) on the Android system.

[0042] Step b: The first upper-layer application obtains the account identity token from the server backend through account login. This corresponds to step 110.

[0043] Step c: If the first upper-layer application calls the account identity token storage interface through the Unified Identity Service (UES) and initiates the call request through the UES (located in the Rich Execution Environment REE), then the UES (located in the REE) loads the pVM (i.e., the security virtual machine) and creates a communication channel between the REE and the pVM (steps d to g). If the upper-layer application directly initiates the call request through the UES (pVM), then the module directly responds to the request. Since this is done in the pVM environment, the first upper-layer application does not need to verify the pVM identity again and proceeds directly to step h.

[0044] Step d: The first upper-layer application requests the "identity credentials" of pVM and sends an authentication request to pVM through the AVF Binder communication mechanism.

[0045] Step e: After receiving the request, pVM uses the virtual machine private key generated during pVM creation to sign the "request content + timestamp + random number" to generate an identity credential. This credential includes: a unique identifier for pVM (such as the hash value of the pVM public key), the timestamp of the request, the random number, and the version information of Microdroid OS.

[0046] Step f: After receiving the identity credentials, the first upper-layer application uses the pVM's public key (i.e., the virtual machine's public key) to verify the signature's validity. The verification is successful if: the signature content matches the request content; the virtual machine's public key has not been tampered with; and the timestamp is within a valid range. If the verification is successful, the verification result and the virtual machine's public key are returned to the upper-layer application. This corresponds to step 160.

[0047] Step g: The first upper-layer application uses the virtual machine's public key to encrypt the identity token. This corresponds to step 120.

[0048] Step h: The first upper-layer application requests the unified identity service (located in pVM) to save the identity token. This corresponds to step 130.

[0049] Step i: Upon receiving a request, the Unified Identity Service (located in pVM) verifies, through its permission management module, whether the application has the permission to call the interface. If the permission verification is successful, pVM requests the Unified Identity TA (located in the Trusted Execution Environment) to save or update the identity token. Step j: The Unified Identity TA (located in the Trusted Execution Environment) only accepts requests from the Unified Identity Service (located in pVM). Upon receiving a request, it retrieves the existing list of authorized applications, queries which account ranges the application requesting the write / update of the identity token belongs to, then decrypts the identity token content using the virtual machine's private key, stores it in the shared storage area for these account ranges, and returns the result. This corresponds to step 140.

[0050] Step k: The second upper-layer application can obtain the shared account identity token by calling the account identity token status query interface.

[0051] Step 1: If the second upper-layer application initiates a call request to the pVM through the Unified Identity Service (located in the REE), the Unified Identity Service (located in the REE) loads the pVM and creates a communication channel between the REE and the pVM. If the second upper-layer application initiates a call request through the pVM, no communication channel is created between the REE and the pVM.

[0052] Step m: Upon receiving the request, the Unified Identity API module (pVM) verifies, through the permission management module, whether the second-layer application has the permission to call the interface. If the permission verification is successful, the Unified Identity Service (located in pVM) requests the Unified Identity TA in the Trusted Execution Environment (TEE) to obtain a shareable identity token for the second-layer application. Step n: The Unified Identity TA (located in the TEE) queries the list of authorized applications belonging to which account scopes the second-layer application belongs and obtains the identity token stored for the corresponding account scope. The identity token is encrypted using the protection password set for the account scope. If no password is set, the default password is the account scope identifier. The retrieved account scope identifier and the encrypted identity token are returned to the Unified Identity Service (located in the REE) and then transmitted back to the second-layer application.

[0053] Step o: After the second upper-layer application decrypts the identity token, it uploads the identity token to the backend for verification and returns the result. Steps k to o correspond to step 150.

[0054] Referring to Figure 3, the above-mentioned unified identity recognition method is applied to a real-world scenario, including the following account-sharing application registration process, including steps P to V: Step P: The upper-layer application that needs to share accounts calls the Account-Sharing Application Registration API (Application Programming Interface) in the Unified Identity Recognition Service (REE) and passes in the specified Account Range ID or the application package name of the shared account.

[0055] Step Q: When the Unified Identity Service (REE) module receives the account sharing application registration request initiated by the upper-layer application, it starts the pVM (Secure Virtual Machine) management module and establishes a communication channel between the Unified Identity Service REE (Android OS) and the pVM (MicroDroid OS) through the vSock and Binder mechanisms of AVF. The startup of pVM and the establishment of communication utilize the communication mechanism natively provided by AVF.

[0056] Step R: The Unified Identity Service (REE) forwards the account-sharing application registration request to the Unified Identity Service (pVM) through the communication channel between the REE (Android OS) and pVM (MicroDroidOS). The Unified Identity Service (pVM) also supports direct calls from upper-layer applications within the pVM.

[0057] Step S: After receiving the account-sharing application registration request, the Unified Identity Service (located in pVM) verifies the identity of the requesting application through the Application Identity Authentication module (located in pVM). The Application Identity Authentication module obtains the package name and application signature information of the requesting application through MicroDroid OS, and queries the Unified Identity Service (TA) for verification of the application's identity information through the TEE to the pVM secure channel module.

[0058] Step T: Establishment of the secure channel from TEE to pVM. Through the communication mechanisms of Android OS and Trusted OS, a communication channel is established between the TEE to pVM secure channel module and the Unified Identity TA (TA). Through this channel, as well as the communication channel between the REE and pVM, the Unified Identity TA and the Application Identity Authentication module can transmit information and negotiate session keys. After key negotiation, data between the Unified Identity Service pVM and the Unified Identity can be transmitted encrypted using the session key.

[0059] Step U: In the Unified Identity Authentication (TA), a signature certificate of the pre-configured Account Range Manager is provided. After receiving an application authentication request, the TA compares the signature certificate in the application's signature information with the pre-configured signature certificate of the pre-configured Account Range Manager. If they match, the application is returned as the Account Range Manager.

[0060] Step V: After obtaining the application identity, the application identity authentication module (pVM) verifies the API call permissions through the permission management module (pVM). If the permission verification is successful, the unified identity recognition management module (pVM) executes the account-sharing application registration request, including steps V1 to V3: Step V1: If the application identity requesting account-sharing application registration is the account range administrator corresponding to the passed account range identifier (AccountRange ID), the unified identity recognition management module requests the unified identity recognition TA to add the application to the authorized application list (Account RangeAPP list) of the corresponding account range identifier through the TEE to pVM secure channel, and records the application as the administrator application of the account range. Among them, the account administrator application can perform biometric association such as fingerprint, face, etc. Through the account administrator application, the application and biometric association interface of the unified identity recognition API module is called. After the application identity and permission management authentication, the unified identity recognition management module pops up the biometric selection interface (face, fingerprint, iris, etc.), and the user selects the biometric method of application management and enters information. The unified identity module requests the unified identity TA to associate and store the application with the entered biometric information. The account administrator application and the account administrator's biometric information can be protected with passwords for the corresponding account scope.

[0061] Step V2: If the application requesting account-sharing application registration provides an application package name, the Unified Identity Management module queries the Unified Identity TA to see if the provided application package name is already in the authorized application list, including steps V2-1 to V2-2: Step V2-1: If the queried package name is in the authorized application list, the corresponding account scope identifier list is returned. The Unified Identity Management module displays an account scope identifier list selection interface, prompting the user to select whether to allow account-sharing application registration and which account scope identifier to register to. If the user selects an account scope identifier, the Unified Identity Management module requests the Unified Identity TA to add the requesting application to the corresponding authorized application list.

[0062] Step V2-2: If the queried package name is not in the authorized application list, the Unified Identity Management module will display a prompt page indicating that the queried shared account application is not registered and asking whether to continue account sharing. If the user chooses to continue, the Unified Identity Management module will request the Unified Identity TA to create a new account scope, add the application applying for registration to the authorized application list, and return the account scope identifier.

[0063] Step V3: If a request for account-sharing application registration is made without providing an account scope identifier or the application package name for the shared account, the Unified Identity Management module will display an existing account scope identifier, prompting the user to choose to add the application to an existing account scope for account sharing, or to create a new account scope. Based on the user's choice, the application will be added to the selected account scope or a new account scope will be created to add the registered application.

[0064] Optionally, applying the above-mentioned unified identity recognition method to a real-world scenario also includes a biometric recognition process, including steps A to I: Step A: The upper-layer application requests the required login method, biometric recognition (face recognition / fingerprint recognition / iris recognition, etc.), through the unified identity recognition API module's unified identity recognition interface.

[0065] Step B: The application initiates a call request through the Unified Identity API module (located in REE), or directly from the Unified Identity API module (located in pVM).

[0066] Step C: After receiving a biometric request, the Unified Identity API module (located in pVM) verifies whether the application has permission to invoke biometrics through the permission management module.

[0067] Step D: If the permission verification is successful, the biometric collaboration module will respond and execute the biometric request selected by the user.

[0068] Step E: The biometric collaboration module (pVM) displays a biometric information collection interface, such as face collection / fingerprint collection / iris collection, after receiving a biometric request.

[0069] Step F: The biometric collaboration module (pVM) requests biometrics from the biometric module (REE). The biometric module (REE) calls the corresponding basic biometric services (face recognition basic service / fingerprint recognition basic service / iris recognition basic service) to initiate the biometric request. The basic biometric services communicate with the HAL layer to collect the corresponding biometric information.

[0070] Step G: The collected biometric information is transmitted from the biometric module (REE) to the biometric system module, and the biometric information collection interface is updated based on the acquired data (such as the face preview interface / fingerprint matching interface).

[0071] Step H: The system's basic biometric service (REE) interacts with the TEE's biometric TAS according to the identified information and existing procedures to complete the biometric verification. The TEE sends the biometric authentication result to the unified identity verification TA. The TEE's biometric TAS returns the verification result to the biometric module. The biometric module then sends the result back to the biometric collaboration module.

[0072] Step 1: After receiving the identification result forwarded by the biometric module, the biometric collaboration module interacts with the unified identity TA to check whether the result obtained by the unified identity TA is consistent. This ensures that the result returned by the REE biometric basic service has not been tampered with.

[0073] Referring to Figure 2, the present invention also provides an electronic device 400, including a memory 402, a processor 401, and a computer program stored in the memory 402 and running on the processor 401. When the processor 401 executes the computer program, it implements the various steps in the unified identity recognition method described above.

[0074] The beneficial effects of the electronic device of the present invention are the same as those of the method described above, and will not be repeated here.

[0075] In summary, this invention provides a unified identity recognition method and electronic device. Specifically, it involves running a secure virtual machine, at least two upper-layer applications, and a trusted execution environment (TEU) on an Android system. After successful login, the first upper-layer application obtains an identity token from the login backend and encrypts it to obtain an encrypted identity token. The first upper-layer application then calls the secure virtual machine, which verifies its identity and sends the encrypted identity token to the TEU. Encryption ensures secure transmission of the identity token. The TEU decrypts the encrypted identity token and stores it in a shared storage area. The secure isolation features of the TEU ensure the confidentiality of the stored identity token. The second upper-layer application calls the secure virtual machine to obtain an identity token. After verification, the secure virtual machine retrieves the identity token from the shared storage area and returns it to the second upper-layer application to complete the login. The encrypted identity token is decrypted and stored in the shared storage area, allowing the second upper-layer application to obtain the identity token directly from the shared storage area. This allows the second application to obtain the identity token directly from the shared storage area without logging in, ensuring secure sharing of identity information. This improves the overall security and processing efficiency of identity recognition under the Android system. Furthermore, by employing cryptographic pairing operations of private key signing and public key verification, the non-forgeability and transmission integrity of virtual machine identity credentials are ensured, while the authenticity of the identity is double-verified through request content comparison. This effectively prevents man-in-the-middle attacks and identity impersonation risks while establishing cross-domain communication trust relationships.

[0076] The above are merely embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention's specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A unified identity recognition method, characterized in that, An application is provided for an Android system, wherein a rich execution environment, a secure virtual machine, and a trusted execution environment run on the Android system, and at least two upper-layer applications run on the rich execution environment. The method includes: after a first upper-layer application successfully logs in, it obtains an identity token from the login backend; the first upper-layer application encrypts the identity token to obtain an encrypted identity token; the first upper-layer application calls the secure virtual machine, and after the secure virtual machine verifies the identity of the first upper-layer application, it sends the encrypted identity token to the trusted execution environment; the trusted execution environment decrypts the encrypted identity token to obtain an identity token and stores it in a shared storage area; the second upper-layer application calls the secure virtual machine, and after the secure virtual machine verifies the identity of the second upper-layer application, it obtains the identity token from the shared storage area and returns it to the second upper-layer application to complete the login.

2. The unified identity recognition method according to claim 1, characterized in that, After the first upper-layer application successfully logs in and obtains an identity token from the login backend, the process further includes: the first upper-layer application sending a virtual machine authentication request to the secure virtual machine through the rich execution environment; the secure virtual machine using its private key to digitally sign the virtual machine authentication request, generating a digital signature; the secure virtual machine combining the virtual machine authentication request and the digital signature to generate an identity credential and sending it to the rich execution environment; after receiving the identity credential, the rich execution environment using the secure virtual machine's public key to verify the legality of the digital signature in the identity credential; if legal, it determines whether the virtual machine authentication request in the identity credential is the same as the generated virtual machine authentication request; if so, it sends the public key to the first upper-layer application.

3. The unified identity recognition method according to claim 2, characterized in that, Also includes: The secure virtual machine obtains the timestamp of the virtual machine authentication request; The secure virtual machine generates random numbers; The secure virtual machine uses its private key to digitally sign the virtual machine authentication request. Generating the digital signature involves the secure virtual machine signing its unique identifier, version information, the virtual machine authentication request, the timestamp, and the random number. Upon receiving the identity credential, the rich execution environment (REMO) verifies the digital signature in the identity credential using the secure virtual machine's public key. If the verification is successful, it obtains the virtual machine authentication request, timestamp, and random number from the identity credential. The REMO verifies whether the virtual machine authentication request in the identity credential matches the generated virtual machine authentication request, and verifies the validity of the version information, timestamp, and random number. If all verifications are successful, it sends the public key to the first upper-layer application.

4. The unified identity recognition method according to claim 1, characterized in that, The trusted execution environment (TEE) decrypts the encrypted identity token to obtain an identity token and stores it in a shared storage area. This includes: the TEE querying the target account range corresponding to the first upper-layer application; and the TEE decrypting the encrypted identity token using the public key of the secure virtual machine to obtain an identity token and storing it in the shared storage area of ​​the target account range.

5. The unified identity recognition method according to claim 1, characterized in that, Also includes: The first upper-layer application sends an identity token save request to the security virtual machine, the identity token save request including the encrypted identity token; The secure virtual machine verifies the permission of the identity token saving request. If the verification is successful, it sends the identity token saving request to the trusted execution environment.

6. The unified identity recognition method according to claim 1, characterized in that, Also includes: The shared application registration request initiated by the first upper-layer application is transmitted to the secure virtual machine through the rich execution environment. The shared application registration request includes a registration identifier. The secure virtual machine sends an authentication request corresponding to the shared application registration request to the trusted execution environment. The authentication request includes a signature certificate corresponding to the first upper-layer application. The Trusted Execution Environment (TEE) compares the signing certificate with the administrator signing certificate corresponding to the registration identifier pre-set in the TEE. If they match, the TEE sends the application identity of the first upper-layer application as the administrator identity corresponding to the registration identifier to the security virtual machine. Upon receiving the administrator identity, the security virtual machine verifies the calling permissions of the first upper-layer application. If the verification is successful, the TEE sends an administrator application addition request to the TEE, which includes the registration identifier. The TEE adds the first upper-layer application to the authorized application list corresponding to the registration identifier and identifies the first upper-layer application as the administrator application corresponding to the registration identifier.

7. The unified identity recognition method according to claim 6, characterized in that, After the secure virtual machine sends an authentication request corresponding to the shared application registration request to the trusted execution environment, the process further includes: the trusted execution environment comparing the signing certificate with the administrator signing certificate corresponding to the registration identifier pre-set in the trusted execution environment; if they do not match, the trusted execution environment sends a message to the secure virtual machine stating that the application identity of the first upper-layer application is the non-administrator identity corresponding to the registration identifier; upon receiving the non-administrator identity, the secure virtual machine verifies the calling permissions of the first upper-layer application; if the verification passes, the trusted execution environment sends a normal application joining request, the normal application joining request including the registration identifier; and the trusted execution environment adds the first upper-layer application to the normal application list corresponding to the registration identifier.

8. The unified identity recognition method according to claim 1, characterized in that, The second upper-layer application invokes the secure virtual machine. After verifying the identity of the second upper-layer application, the secure virtual machine obtains the identity token from the shared storage area and returns it to the second upper-layer application to complete the login. This includes: the second upper-layer application sending a request to obtain an identity token to the secure virtual machine; the secure virtual machine verifying the permissions of the second upper-layer application, and after successful verification, sending the request to obtain an identity token to the trusted execution environment; the trusted execution environment querying the target account range corresponding to the second upper-layer application; the trusted execution environment obtaining the shared storage area corresponding to the target account range; the second upper-layer application obtaining a first identity token from the shared storage area through the secure virtual machine; and the second upper-layer application decrypting the first identity token to obtain a second identity token to complete the login.

9. The unified identity recognition method according to claim 1, characterized in that, The second upper-layer application invokes the secure virtual machine, including: the second upper-layer application sending an identity token acquisition request to the rich execution environment; the rich execution environment initiating the establishment of a secure channel between the rich execution environment and the secure virtual machine; and the rich execution environment sending the identity token acquisition request to the secure virtual machine through the secure channel.

10. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of a unified identity recognition method according to any one of claims 1 to 9.

Images