WO2023072206A1

WO2023072206A1 - Key migration method and related device

Info

Publication number: WO2023072206A1
Application number: PCT/CN2022/127998
Authority: WO
Inventors: 漆昌桂; 胡慧锋
Original assignee: 华为技术有限公司
Priority date: 2021-10-29
Filing date: 2022-10-27
Publication date: 2023-05-04
Also published as: CN116070222A

Abstract

A key migration method and a related device. After determining that an application changes a UID, a terminal device can restore a key file, which is stored on a KeyStore service side before the application changes the UID, that is, key migration can be implemented by means of migrating data that has been stored in one key file into another new key file, thereby ensuring that, after the application changes the UID, when the application searches for a key file by using a file name of a key file that is generated on the basis of the changed UID, a correct key file (i.e. the new key file) can be found, such that encrypted data can be successfully decrypted by using the correct key file, thereby avoiding decryption failure and the loss of the encrypted data, improving service continuity, and improving the user experience.

Description

Key migration method and related equipment

This application claims priority to a Chinese patent application filed with the State Intellectual Property Office of China on October 29, 2021 with application number 202111279912.3 and titled "Key Migration Method and Related Equipment", the entire contents of which are hereby incorporated by reference Applying.

technical field

The present application relates to the technical field of communications, and in particular to a key migration method and related equipment.

Background technique

With the popularization of smart terminal devices and the development of Internet technology, some terminal devices such as smart phones, notebook computers, and tablet computers have become indispensable products in people's daily life. In order to meet the increasing demands of users, the types and quantities of applications installed on these terminal devices are also increasing.

Usually, system applications on terminal devices are granted high authority. Once these system applications are compromised, it will cause security risks such as system configuration manipulation, user data and system data leakage, and bring huge security risks to the system. Therefore, it is necessary to change and rectify the user identification (UID) of these system applications. Since the terminal device searches for the key file based on the UID of the application, after the UID of the application is changed, the terminal device cannot find the key file stored under the old UID (the UID before the change) according to the new UID (the UID after the change). Therefore, the new UID application cannot decrypt the encrypted data of the old UID application, further resulting in loss of encrypted data, reduced service continuity, and poor user experience.

Contents of the invention

The embodiment of the present application provides a key migration method and related equipment, which can guarantee service continuity and user experience when the UID of an application is changed.

In the first aspect, the embodiment of the present application provides a key management method, which is applied to a terminal device, and the terminal device is installed with a first application. The method includes: the terminal device changes the user identity certificate UID of the first application from the first UID to is the second UID, the first application accesses the first key file based on the user identity certificate UID of the first application, and the data stored in the first key file is required for the first application to execute the first business, the second The file name of a key file is generated by the terminal device based on the first UID; the terminal device generates a second key file based on the first key file; wherein, the file name of the second key file is generated by the terminal device based on the second UID Yes, the data stored in the second key file is the same as the data stored in the first key file.

By implementing the method provided by the embodiment of this application, after the terminal device determines that the application has changed the UID, it can repair the key file of the application stored on the KeyStoreService side before the change of the UID, that is, the key file can be stored in a stored key file. The data of the key file is migrated to another new key file to realize the key migration, so as to ensure that after the application changes the UID, when the application uses the file name of the key file generated based on the changed UID to search for the key file, it can find The correct key file (that is, the new key file), so that the encrypted data can be successfully decrypted by using the correct key file, avoiding decryption failure and loss of encrypted data, improving business continuity and improving user experience.

In a possible implementation manner, the terminal device generates the second key file based on the first key file, which specifically includes: the terminal device migrating the data stored in the first key file to the second key file; or, the terminal device Generate the second key file by changing the file name of the first key file to the file name of the second key file.

In this way, when the application uses the file name of the key file generated based on the changed UID to search for the key file, the correct key file can be found, so that the encrypted data can be successfully decrypted by using the correct key file.

In a possible implementation, before the terminal device changes the UID of the first application from the first UID to the second UID, the method further includes: the terminal device restarts after completing the OTA upgrade over the air; or, the terminal device completes the over-the-air update After the OTA is upgraded, it is detected that the user logging in to the terminal device is switched from the first user to the second user.

In this way, the terminal device can be triggered to perform an operation of querying the UID, so as to determine whether the UID of the application has changed.

In a possible implementation manner, before the terminal device changes the UID of the first application from the first UID to the second UID, the method further includes: the terminal device detects that the first application is started and running.

In a possible implementation manner, the terminal device includes an application package management service PMS, and before the terminal device generates the second key file based on the first key file, the method further includes: the terminal device detects the The UID is changed from the first UID to the second UID.

In this way, the terminal device can determine whether the UID of the application has changed through the PMS.

In a possible implementation manner, the terminal device includes a key store service KeyStoreService, and before the terminal device generates the second key file based on the first key file, the method further includes: the terminal device detects the The UID is changed from the first UID to the second UID.

In this way, the terminal device can determine whether the UID of the application has changed through the KeyStoreService.

In a possible implementation manner, the terminal device includes an Installd module, and before the terminal device generates the second key file based on the first key file, the method further includes: the terminal device queries the first UID and the second UID through the Installd module .

In this way, the terminal device can query the UID through Installd.

In a possible implementation manner, the terminal device uses the data stored in the second key file to execute the first service, which specifically includes: the terminal device displays the first user interface, the first user interface includes user data, and the user data is obtained by using The data stored in the second key file is retrieved.

In this way, the terminal device can use the new key file to decrypt the user data, thereby ensuring that the user data is not lost.

In a possible implementation manner, when the UID of the first application is changed from the first UID to the second UID, the system access authority of the first application becomes lower.

In this way, the system access authority of the application can be reduced by changing the UID, thereby improving security.

In a possible implementation manner, after the terminal device generates the second key file based on the first key file, the method further includes: the terminal device checks the key integrity of the second key file, and confirms the check Pass; and/or, the terminal device checks the authority of the second key file, and confirms that the check is passed.

In this way, by performing key integrity check and file permission check on the new key file, key tampering can be prevented and potential hidden dangers of key being illegally manipulated can be eliminated.

In a possible implementation manner, before the terminal device generates the second key file based on the first key file, the method further includes: the terminal device confirms that the first application allows the terminal device to generate the second key file based on the first key file; key file; and/or, the terminal device checks the key integrity of the first key file, and confirms that the check passes; and/or, the terminal device checks the authority of the first key file, and confirms that the check passes.

In this way, key integrity checks and file authority checks can be performed on old key files to prevent key tampering and eliminate potential hidden dangers of keys being illegally manipulated.

In a possible implementation manner, after the terminal device generates the second key file based on the first key file, the method further includes: the terminal device saves the second key file.

In this way, the terminal device can find the key file corresponding to the key when it needs to obtain the key.

In a possible implementation manner, the first application is a system application, and the system application is an application preset by an operating system of the terminal device.

In a possible implementation manner, the UID of the first application is generated based on the user identifier UserId and the application identifier APPId, wherein the user identifier UserId is determined by the terminal device based on the number of users who log in to the terminal device, and the application identifier APPId is determined by the terminal device Determined based on the package name of the first application.

In a second aspect, an embodiment of the present application provides a terminal device, the terminal device includes one or more processors and one or more memories; wherein, the one or more memories are coupled to the one or more processors, and one or more The multiple memories are used to store computer program codes, and the computer program codes include computer instructions. When one or more processors execute the computer instructions, the terminal device executes the method in any possible implementation manner of the first aspect above.

In a third aspect, an embodiment of the present application provides a computer storage medium, the computer storage medium stores a computer program, the computer program includes program instructions, and when the program instructions are run on a terminal device, the terminal device executes any of the above-mentioned first aspects. Method in one possible implementation.

In a fourth aspect, an embodiment of the present application provides a computer program product, which, when the computer program product is run on a computer, causes the computer to execute the method in any possible implementation manner of the first aspect above.

Description of drawings

Fig. 1A-Fig. 1B are a set of user interface diagrams provided by the embodiment of the present application;

2 is a schematic flow diagram of a key migration method triggered to be executed under the scenario of a PMS scanning application package provided by an embodiment of the present application;

FIG. 3A-FIG. 3H are schematic diagrams of user interfaces for a group of OTA upgrades and multi-user switching provided by the embodiment of the present application;

FIG. 4 is a schematic flow diagram of a key migration method triggered to be executed in another PMS scanning application package scenario provided by an embodiment of the present application;

Fig. 5 is a schematic flowchart of a key migration method that is triggered to be executed in a scenario where an application needs to obtain a key during startup and operation provided by an embodiment of the present application;

Fig. 6 is a schematic flowchart of another key migration method triggered by execution in a scenario where an application needs to obtain a key during start-up and running according to an embodiment of the present application;

FIG. 7 is a schematic structural diagram of a terminal device provided in an embodiment of the present application;

FIG. 8 is a schematic diagram of a software architecture of a terminal device provided in an embodiment of the present application.

Detailed ways

The technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Among them, in the description of the embodiments of this application, unless otherwise specified, "/" means or means, for example, A/B can mean A or B; "and/or" in the text is only a description of associated objects The association relationship indicates that there may be three kinds of relationships, for example, A and/or B, which may indicate: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiment of the present application , "plurality" means two or more than two.

It should be understood that the terms "first" and "second" in the specification, claims and drawings of the present application are used to distinguish different objects, rather than to describe a specific order. Furthermore, the terms "include" and "have", as well as any variations thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, system, product or device comprising a series of steps or units is not limited to the listed steps or units, but optionally also includes unlisted steps or units, or optionally further includes For other steps or units inherent in these processes, methods, products or apparatuses.

Reference in this application to an "embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the present application. The occurrences of this phrase in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. It is understood explicitly and implicitly by those skilled in the art that the embodiments described in this application can be combined with other embodiments.

For ease of understanding, some related concepts involved in the embodiments of the present application are described below.

1. Keystore System (KeyStoreSystem)

Taking the Android KeyStore System as an example, the Android KeyStore System is a keystore management system, which consists of the KeyChain application programming interface (Application Programming Interface, API) introduced in Android 4.0, Android 4.3 The Android keystore provider function introduced in . The Android keystore system can store encryption keys in containers, thereby providing the difficulty of extracting the keys in the device. After the keys are in the keystore, they can be used for cryptographic operations, while the key material remains non-exportable. The Android keystore system protects key material from unauthorized use.

The Android keystore system can be divided into three parts at the architectural level:

The first part: Android Key Store (AndroidKeyStore), located in the framework (Framework) layer, is used to provide relevant interfaces for key operations to the application layer.

The second part: the key store service module (KeyStoreService), located in the native (Native) layer, is responsible for the management and storage of keys, corresponding to the process keystore.

The third part: Keymaster trusted application (Trusted Application, TA), which runs in a trusted security environment (Trusted Execution Environment, TEE), used to provide key generation, data encryption and decryption, authentication, signature verification and other related security services realization.

Some applications on the terminal device can use the Android keystore system to encrypt and decrypt their data, and their key files (also called key index files) will be stored in the data directory of the keystore service module. Usually, The key file under the management of the Android key store system, its file name is generated based on encoding the UID, key type, and key alias (Alias) of the application, for example, the file name of a certain key file is 1000_USRPKEY_XX, then the UID of the application is 1000, the key type is USRPKEY, and the key alias is XX. The key store service module can use the key file as the key entry, and call KeymasterTA to perform data encryption and decryption related operations.

It should be noted that the key store system may include but not limited to the Android key store system. Limitations on this Application.

2. User identification (UID)

For a multi-user system such as the Linux system, each user has a UID, which is mapped to the user name one by one. In order to facilitate user management, multiple users can be assigned to a group, and each group has A group ID (GroupIdentification, GID).

Before Android 4.2, the Android system did not support multiple users. After Android 4.2, the multi-user function was added. That is to say, multiple users can be added to one Android device. User types can include primary users, secondary users, guest user. Among them, the primary user is the first user added to the device. Unless the factory settings are restored, the primary user cannot be removed. Other users are running in the foreground, and the primary user will always be running; the secondary user is in addition to the primary user. Any user added to the device, the secondary user can be removed (either by the user himself or by the primary user) without affecting other users on the device, the secondary user can run in the background and continue to be connected to the network ;Guest user is a temporary secondary user, the system provides an explicit option to delete the guest user, when the guest user is no longer using the device, it can be quickly deleted, there can only be one guest user at a time.

For the Android system, UID is an Android application identity based on a specific user. Usually, a UID corresponds to an application, and the UID of an application is the application package management service module (PackageManagerService, PMS) in parsing and installing Android applications. Created when the package (AndroidApplicationPackage, APK) file. All processes in the same Android application share the same UID. If you want to share the same UID between multiple different Android applications, you need to set the same sharedUserId in the XML file of "AndroidManifest.xml", and have the same signature at the same time .

The multi-user Android system introduces two new concepts: user identifier (UserIdentifier, User Id) and application identifier (ApplicationIdentifier, App Id).

Wherein, the User Id is related to the number of users (such as primary users, secondary users, guest users, etc.) on the terminal device. If there is only one user on the terminal device, that is, single-user status, the User Id of the user is 0; if there are multiple users on the terminal device, that is, multi-user status, each user has its own User Id, and They are different from each other. Except for the default user (the User Id of the default user is 0), the User Id of other users increases sequentially from 10.

Among them, the App Id is related to the application on the terminal device. Even for different users, applications with the same application package name (package name for short) have the same App Id. That is to say, once the application is deployed, its App Id will be fixed. , will not change during normal operation of the system.

There are two ways to determine the App Id: the first way is automatically assigned by PMS, which is usually applicable to third-party applications, or some system applications; the second way is to specify Android in "AndroidManifest.xml": sharedUserId for fixed allocation, which is usually applicable to most system applications.

UID has the following conversion relationship with User Id and App Id:

UID＝UserId*100000+AppId;

Among them, the value range of App Id is [0,100000]; for User Id, in single user (default user) state, User Id is 0, in multi-user state, default user's User Id is 0, if you add A new user, such as user 1, the User Id of user 1 is 10. If a new user is added, such as user 2, the User Id of user 2 is 11. If a new user is added, such as user 3, the user The User Id of 3 is 12, and so on, that is to say, except the default user (the User Id of the default user is 0), the User Ids of other users increase sequentially from 10, such as 10, 11, 12, 13 and so on.

According to the above-mentioned conversion relationship between UID, User Id and App Id, assuming that the App Id of an application is 5514, for the default user, the User Id is 0, and the UID is 5514, that is, UID=App Id; for user 1 For example, if its User Id is 10, its UID is 1005514. That is to say, for the same application, different users have different UIDs of the application. It is easy to understand that the UID can be used as an identifier to distinguish the same application under different users.

3. Application package management service module (PackageManagerService, PMS)

The PMS is responsible for managing various application packages on the system, can install, uninstall, update and analyze the application packages on the terminal device, and can also be responsible for authority management, etc.

The role of PMS is mainly concentrated in the terminal device startup and restart phase (boot phase), which is responsible for the application package scanning process (that is, the PMS scanning process). This process includes five phases: start phase (boot_progress_pms_start), scan system (system) Partition phase (boot_progress_pms_system_scan_start), scan data (data) partition phase (boot_progress_pms_data_scan_start), scan end phase (boot_progress_pms_scan_end), preparation phase (boot_progress_pms_ready).

In the initial stage, many PMS objects can be created by calling the main method, and assigned to member variables in the PMS (such as mSettings, mInstaller, systemConfig, etc.).

In the stage of scanning the system partition, PMS will scan the application package under the /system directory (system directory). /system can be called the system partition, which is mainly used to store Android system-related files and frameworks. directory, PMS will scan the files in each subdirectory, such as /system/app (the subdirectory of /system where the system APP is stored), /system/framework (the subdirectory of /system where the application framework layer jar package is stored) and other directories files under , and do some post-processing on the scanned files.

In the phase of scanning data partitions, PMS will scan the application packages under the /data directory (data directory). /data can be called the data partition. This partition is mainly used to store personal data and configuration files of all users. The /data directory includes Multiple subdirectories, PMS will scan the files in each subdirectory, such as /data/app (the subdirectory of /data storing the third-party APP), /data/system (the subdirectory of /data storing the system configuration files), / data/data (the subdirectory of /data that stores all the data of the installed APP) and other directories, and update the application information in the data directory in time to remove unnecessary data.

The UID information of the applications involved in the embodiments of the present application are all stored in the /data directory.

At the end of the scan, the PMS can determine whether the current platform software development kit (Software Development Kit, SDK) version is different from the SDK version at the last startup, and if so, update the permissions; it can also determine whether it is the first time after the OTA upgrade Start, if so, clear unnecessary buffer data; you can also update files such as package.xml.

In the preparation phase, PMS will create PackageInstallerService object, perform memory garbage collection, etc.

The PMS installs and uninstalls the application package on the terminal device mainly through Installer and Installd. Among them, Installer is the API interface provided by the Java layer, and Installd is the DaemonService started by the init process.

Usually, the system application on the terminal device is granted high authority. For example, by setting Android:sharedUserId="android.uid.system", the system application can be run in the system process, and the system application has the system authority ( For example, root authority), you can modify the system configuration, and at the same time, you can also configure multiple applications to run in one process for data sharing. In this way, the high authority of system applications can easily bring huge security risks to the system. Once these system applications are compromised, it will cause security risks such as system configuration manipulation, user data and system data leakage. Therefore, in order to reduce security risks, it is necessary to change and rectify the UIDs of these system applications. For example, the AppId of the system applications can be changed by removing the attribute of the system application Android:sharedUserId="android.uid.system", thereby further changing the The UID of the system application is indicated, where the system application may refer to an application preset in the operating system (Operting System, OS) of the terminal device, such as applications such as setting, information, and dialing.

The UID change of the application will cause the data resources of the application with the old UID (that is, the UID before the change) to be unavailable for the application with the new UID (that is, the UID after the change). That is to say, after the UID of the application is changed, the user cannot access the application. The original directory file before changing the UID, resulting in data loss.

In view of the above problems, the current solution is to repair the group and permissions of the application's data directory, so that the new UID application also has access to the old UID application's data directory, so that after the application's UID is changed, the old UID The data of the application is still available for the new UID application, that is, the user can normally access the data directory of the old UID application.

The specific implementation process of this solution is as follows:

First, in the process of scanning the application package by the PMS, for each application on the terminal device, the PMS will call the Installd process to prepare user data.

Further, by calling the Installd process to scan the UID/GID to which the data directory of the current application belongs, the data directory includes the data directory under the credential encrypted (CredentialEncrypted, CE) storage space and the device (Device Encrypted, DE) encrypted storage space. Data directory, among which, the CE storage space is the default storage location available for applications, which can only be used after the user unlocks the terminal device; the DE storage space is available to the terminal device in the direct startup mode and after the user unlocks the terminal device .

Further, after the scanning, if it is determined that the UID/GID to which the data directory belongs has changed, repair is performed, and the original UID/GID is changed to a changed UID/GID.

However, for some applications that use the Android Keystore System (AndroidKeystoreSystem) to encrypt and decrypt data, the key files used are uniformly managed by the KeyStoreService module (KeyStoreService). The file name is generated by KeyStoreService based on the encoding of the application's UID, key type, and key alias. After changing the UID of the application, not only the UID of the data directory of the application will change, but also the expected file name of the key file in the Android keystore used by the application (that is, the file name generated based on the changed UID) Change, the above solution does not take into account the change of the expected file name of the key file in the Android keystore caused by the change of the UID of the application. Therefore, after the UID of the application is changed, the new UID application calls the Android keystore When decrypting data, KeyStoreService will encode and generate the file name of the new key file based on the new UID (that is, the expected file name), but because the file name of the key file stored in the Android key store does not change with the application Therefore, KeyStoreService cannot find the key file corresponding to the file name of the new key file based on the file name of the new key file, and the new UID application cannot apply to the old UID. If the encrypted data is successfully decrypted, that is, the decryption fails. The failure of the decryption may lead to loss of application data, invalidation of the account information logged into the application, the need for the user to re-sign the relevant agreement, loss of user data, etc., resulting in reduced business continuity at the upper layer , poor user experience.

For example, as shown in FIG. 1A, before the UID of the application is changed, the user interface 100 displays the user's account information (such as account name Mary, etc.) and historical data information (such as my History data recorded in lists such as favorites, recent play, downloads, etc.), that is to say, the terminal device 100 stores the user's account information and historical data information generated during the use of the application before the UID of the application is changed. After the UID of the application is changed, as shown in FIG. 1B , the user interface 110 no longer displays the account information of the user stored on the terminal device 100 before the UID of the application is changed, and the user’s account information generated during the use of the application before the UID of the application is changed. The historical data information is also cleared (for example, the number of data entries stored in the "My Favorites" list is changed from 30 in Fig. 1A to 0 in Fig. 1B), that is to say, the terminal device 100 has no information about the old UID The application's encrypted data decryption failed, resulting in the loss of encrypted data.

To solve the above-mentioned problem that decryption of encrypted data fails because the UID of the application changes but the file name of the key file stored on the KeyStoreService side does not change, the embodiment of this application provides a key migration method. When the terminal device determines that the UID of the application changes After that, the key file stored on the KeyStoreService side of the application before changing the UID can be repaired, that is, the key migration can be realized by migrating the data in a stored key file to another new key file, This ensures that after the application changes the UID, when the application uses the file name of the key file generated based on the changed UID to search for the key file, it can find the correct key file (that is, the new key file), so that the application can use the key file. The correct key file can successfully decrypt encrypted data, avoid decryption failure and encrypted data loss, improve business continuity, and improve user experience.

In the embodiment of the present application, the terminal device can change the UID of the application through Over The Air (OTA). The change of the UID of the application means that under the same user, the UID of the application is different before the OTA and after the OTA.

The key migration method provided in the embodiment of this application can be triggered to execute in the following two scenarios:

1. The execution of the PMS scanning application package is triggered, wherein the triggering condition of the PMS scanning application package is: the terminal device 100 is restarted after the completion of the OTA, or the terminal device 100 responds to the switch user’s request after the completion of the OTA. Operation to perform multi-user switching (for example, switch from default user to user 1). In this scenario, the key migration method provided by the embodiment of the present application can uniformly repair the file names of the key files stored by multiple applications on the KeyStoreService side.

2. The application is triggered to execute when it needs to obtain the key (that is, needs to query the key file) during the startup and running process. In this scenario, the key migration method provided by the embodiment of the present application only repairs the file name of the key file currently stored by a single application on the KeyStoreService side.

The specific process of triggering the execution of the key migration method in these two scenarios will be introduced in detail in subsequent embodiments, which will not be expanded here.

The terminal device 100 in the embodiment of the present application takes a mobile phone as an example, and the terminal device 100 may also be a tablet computer (Pad), a smart screen, a personal digital assistant (Personal Digital Assistant, PDA), a laptop computer ( Laptop) and other smart terminal devices, the embodiment of the present application does not limit the type, physical form, and size of the terminal device 100 .

The key migration method provided in the embodiment of this application can be applied to the UID change scenario of the system application on the terminal device 100 using the Android keystore system for data encryption and decryption, but is not limited thereto. The key migration method provided in the embodiment of the application It may also be applicable to UID change scenarios of other applications on the terminal device 100 that use the Android keystore system for encryption and decryption, which is not limited in this embodiment of the present application.

The following introduces a key migration method triggered for execution in a scenario where a PMS scans an application package provided by an embodiment of the present application.

FIG. 2 exemplarily shows a flow of a method for triggering execution of key migration in a scenario where a PMS scans an application package provided by an embodiment of the present application. As shown in FIG. 2, the method can be applied to a terminal device 100, wherein the terminal device 100 can include: an application package management service module (PMS), an Installer, a service management module (ServiceManager), Installd, and an Android Keystore (AndroidKeystore) , Keystore service module (KeyStoreService).

The specific steps of the method are described in detail below by taking the UID change of the system application on the terminal device 100 as an example:

The terminal device 100 can first obtain the new UID and the old UID of the application, and if it is determined that the new UID and the old UID are different, the terminal device 100 can perform key migration again, so as to ensure that the application can still decrypt data after changing the UID. The correct key file can be found to decrypt the encrypted data, avoiding decryption failure and loss of encrypted data.

Exemplarily, a possible implementation manner for the terminal device 100 to acquire the new UID and old UID of the application may be the implementation described in the following phase one (step S201-step S207), and the specific execution process of phase one is introduced in detail below :

Phase 1 (step S201-step S207): Obtaining the old and new UID phase

S201-S202, the application package management service module of the terminal device 100 sends a request to the Installer for querying the old and new UIDs after detecting that the OTA is completed and restarted or multi-user switching.

Triggering the terminal device 100 to perform the OTA upgrade may include but not limited to the following two implementations:

Implementation mode 1: the terminal device 100 automatically prompts the user to perform an OTA upgrade, and after the user agrees, triggers the terminal device 100 to perform an OTA upgrade.

Exemplarily, referring to FIG. 3A , the terminal device 100 may display a pop-up window 300 for prompting the user to update the system version, and the pop-up window 300 may include a prompt message (such as "found a new version of the system") and an "update now" option 301 , the terminal device 100 may detect the user's operation (such as a click operation) on the "update now" option 301, and in response to the operation, the terminal device 100 may perform a system update, that is, perform an OTA upgrade.

Implementation Mode 2: The user actively enters the "Settings" application to trigger the terminal device 100 to perform OTA upgrade.

Exemplarily, referring to FIG. 3B, FIG. 3B exemplarily shows a user interface 310 of the "Settings" application of the terminal device 100, and the user interface may display multiple setting options (such as "user and account" option 311, " System and Update" option 312, etc.), the terminal device 100 can detect the user's operation (for example, click operation) on the "System and Update" option 312, and in response to the operation, the terminal device 100 can display the exemplarily shown in Figure 3C Further, the terminal device 100 can detect the user's operation (such as a click operation) on the "software update" option 321, and in response to the operation, the terminal device 100 can display the user interface as exemplarily shown in Figure 3D 330, the user interface displays prompt information (for example, "new version found") and an "update now" option 331, and the terminal device 100 may detect the user's operation (for example, click operation) on the "update now" option 331, and respond to the Operation, the terminal device 100 can perform a system update, that is, perform an OTA upgrade.

After the terminal device 100 completes the OTA upgrade, it can automatically start and restart, and display a user interface 340 as shown in Figure 3E. Power on and restart.

Referring to FIG. 3F-FIG. 3H, FIG. 3F-FIG. 3H exemplarily show the process of multi-user handover after OTA is completed.

The terminal device 100 may detect the user's operation (such as a click operation) on the "user and account" option 311 in FIG. It can be seen that the user who currently logs in to the terminal device 100 is the owner user (also referred to as the default user), the terminal device 100 can detect the user's operation on the option 351 (such as a click operation), and in response to this operation, the terminal device 100 can A user interface 360 as shown in FIG. 3G is displayed, and the user interface displays multiple options (such as option 361, option 362, etc.), and it can be seen that there are two users who can log in to the terminal device 100: the owner user and User 1, the user who currently logs in to the terminal device 100 is the owner user, if the user wants to switch to user 1 to log in to the terminal device 100, then the terminal device 100 can detect the user's operation on option 362 (such as a click operation), and respond to In this operation, the terminal device 100 can display a pop-up window 370 as shown in FIG. The user who logs in to the terminal device 100 is switched from the owner user to user 1, thus completing the multi-user switching.

After the terminal device 100 performs a power-on restart process (see FIG. 3E ) after the completion of the OTA or detects the operation of multi-user switching after the completion of the OTA (for example, the user's operation on option 371 in FIG. 3H ), the application of the terminal device 100 can be triggered. The package management service module executes the process of scanning application program packages, scans all application program packages under the currently logged-in user in the system, and repairs its data directory.

In the embodiment of the present application, the application package management service module of the terminal device 100 starts to scan the application package after detecting that the OTA is completed and restarted or multi-user switching is completed. Taking the scanning system application 1 as an example, The application package management service module may also send a request to the Installer for querying the old and new UIDs, the request may carry information such as the package name of the system application 1, and the request is used to instruct the Installer to query the new UID and the old UID of the system application 1, wherein, The new UID refers to the UID of the system application 1 after the OTA upgrade is restarted/after the multi-user switch of the OTA upgrade, and the old UID refers to the UID of the system application 1 before the OTA upgrade is restarted/before the multi-user switch of the OTA upgrade UID.

After the Installer of the terminal device 100 receives the request for querying the old and new UIDs, it can send a request for querying the old and new UIDs to Installd. One possible implementation is the implementation described in the following steps S203-S204:

S203-S204, the Installer of the terminal device 100 sends to the service management module a request for obtaining service 1, the service 1 is a service for querying the old and new UIDs, and after receiving the request for obtaining the service 1 sent by the Installer, the service management module sends a query for the old and new UIDs to Installd request.

Specifically, after the Installer of the terminal device 100 receives the request for querying the old and new UIDs sent by the application package management service module, it may send a request to the service management module to obtain service 1, which is a service for querying the old and new UIDs. After the service management module receives the request for obtaining service 1 sent by the Installer, it can send a request to Installd to query the old and new UIDs. The request can carry information such as the package name of the system application 1, and the request is used to instruct Installd to query the system application 1. new UID and old UID.

Among them, the service management module transparently transmits the request for querying the old and new UIDs to Installd through the binder; among them, the binder is an inter-process communication (Inter-Process Communication, IPC) mechanism, which can realize data interaction between multiple processes ; Transparent transmission (that is, transparent transmission) means that in communication, it is only responsible for sending the transmitted content from the source address to the destination address, without making any changes to the transmitted content.

After the Installd of the terminal device 100 receives the request for querying the old and new UIDs, it can send the new UID and the old UID to the application package management service module. One possible implementation is the implementation described in the following steps S205-S207:

S205-S207, the Installd of the terminal device 100 sends the new UID and the old UID to the service management module, and after the service management module receives the new UID and the old UID sent by the Installd, it sends the new UID and the old UID to the Installer, and the Installer receives the service management After the new UID and old UID sent by the module, send the new UID and old UID to the application package management service module.

Specifically, after the Installd of the terminal device 100 receives the request for querying the old and new UIDs sent by the service management module, it can query the new UID and the old UID of the system application 1, and after the Installd queries the new UID and the old UID of the system application 1, The new UID and old UID of system application 1 can be sent to the service management module, and the service management module can send the new UID and old UID of system application 1 to Installer after receiving the new UID and old UID of system application 1 sent by Installd After receiving the new UID and old UID of the system application 1 sent by the service management module, the Installer may send the new UID and old UID of the system application 1 to the application package management service module.

It can be seen that, by executing steps S201-S209 of the first stage, the PMS can obtain the new UID and old UID of all applications installed on the terminal device 100, so as to pave the way for the terminal device 100 to perform the steps in the subsequent stage two, That is, after the above stage 1 is executed, the following stage 2 can be continued. In some embodiments, after the above-mentioned stage 1 is executed, the following stage 2 may not be executed, but other tasks are performed based on the obtained new UID and old UID. For example, after the above-mentioned stage 1 is executed, based on the obtained The new UID and old UID of all applications, the terminal device 100 can determine which applications are sharing the same UID, and can further obtain other relevant information (such as granted permission information) of these applications, so that these applications can be further managed ( For example, rights management), etc.; the terminal device 100 can further determine whether the UID change of the application is successful by judging whether the new UID and the old UID of the same application are different, and so on.

Phase 2 (step S208-step S217): key migration phase

S208. The application package management service module of the terminal device 100 determines the UID change of the application based on the new UID and the old UID.

Specifically, after receiving the new UID and old UID of the system application 1 sent by the Installer, the application package management service module of the terminal device 100 can compare the new UID and the old UID of the system application 1 to determine the new UID and the old UID Whether they are the same, if they are the same, the application package management service module determines that the UID of the system application 1 has not changed, and the application package management service module does not perform the subsequent steps; if not, the application package management service module determines that the UID of the system application 1 has changed, Optionally, the application package management service module will also determine whether the currently processed application belongs to a system application. For example, the application package management service module will determine whether the system application 1 belongs to a system application. If so, the application package management service module will continue to execute next steps.

It should be noted that, the manner in which the application package management service of the terminal device 100 acquires the new UID and the old UID of the application may include but not limited to the manner of acquiring the new UID and the old UID described in the above stage 1.

After the application package management service module of the terminal device 100 determines that the UID has changed, it can send an instruction to migrate the key to the key store service module. One possible implementation is the implementation described in the following steps S209-S211:

S209-S211, the application package management service module of the terminal device 100 sends an instruction to migrate the key to the Android keystore, the instruction includes information such as the package name of the application, the new UID, the old UID, etc., and the Android keystore receives the instruction Afterwards, a request for obtaining service 2 is sent to the service management module, and the service 2 is a key migration service. After receiving the request, the service management module sends an instruction of key migration to the key store service module.

Specifically, after the application package management service module of the terminal device 100 determines that the UID of the system application 1 has changed, it may send an instruction to migrate the key to the Android keystore, and the instruction may include the package name of the system application 1, the new UID, Information such as the old UID. After receiving the key migration instruction sent by the application package management service module, the Android keystore may send a request to the service management module to obtain service 2, which is a migration key service. After the service management module receives the request for obtaining service 2 sent by the Android keystore, it can send an instruction to migrate the key to the keystore service module, which can include the package name, new UID, and old UID of the system application 1 and other information, this command is used to instruct the key store service module to perform the key migration operation.

Wherein, the same as the data transmission method in the aforementioned step S204, the service management module also transparently transmits the above-mentioned key migration instruction to the key store service module through the binder.

S212. The key store service module of the terminal device 100 confirms that the calling authority check, the configuration list check, the key integrity check, and the file attribute check all pass.

Specifically, after receiving the key migration instruction sent by the service management module, the key store service module of the terminal device 100 can first find all key files corresponding to the package name based on the package name of the system application 1, and further , in order to improve security, you can check the call authority, configuration list, key integrity, and file attributes. After confirming that the above four checks are all passed, the key store service module will perform the next steps.

Among them, the specific execution process of the key store service module to perform the above four checks is as follows:

Call authority check: the key store service module confirms whether the IPC peer process calling the key store service process is a system process, and if it is a system process, the key store service module confirms that the call authority check passes.

Configuration list check: The key store service module determines whether the package name of the system application 1 allows key migration based on the configuration information corresponding to the package name of the system application 1 recorded in the configuration list. If it is allowed, the key store service module confirms If the configuration list check is passed, the key store service module will further determine which keys corresponding to the package name of the system application 1 need to be migrated.

Key integrity check: The key store service module verifies the integrity of the key by calling KeymasterTA to prevent the key from being tampered with. If the verification is successful, the key store service module confirms that the key integrity check of all key files corresponding to the package name of the system application 1 passes.

File attribute check: The key store service module checks the attributes and permissions of all key files corresponding to the package name of the system application 1 by calling Installd, so as to eliminate the potential hidden danger of the key being illegally operated.

The embodiment of the present application does not limit the time sequence in which the key store service module performs the above four checks.

In some embodiments, step S212 is optional.

In some embodiments, after one or more of the above four checks pass, the key store service module can execute the next steps.

In a possible implementation, after the keystore service module finds all the key files corresponding to the package name based on the package name of the system application 1, since the file names of all the current key files are based on the old key files of the system application 1 UID, key type, and key alias are encoded and generated. Therefore, the key store service module can determine that the above two UIDs sent by the service management module are received according to the old UID of the application contained in the file name of the key file. (New UID and old UID), which is the old UID and which is the new UID.

S213. The key store service module of the terminal device 100 performs a key migration operation to obtain a new key file.

Specifically, after confirming that the call authority check, configuration list check, key integrity check, and file attribute check all pass, the key store service module of the terminal device 100 can start to perform the key migration operation, that is, the package of the system application 1 All key files corresponding to the name are migrated.

Among them, the key migration operation performed by the key store service module may include but not limited to the following two possible implementation methods. The following uses the key store service module to migrate one of the key files in the above-mentioned key files. Two possible implementations are introduced:

Suppose the old UID is 1000, the new UID is 5514, and the key file needed to decrypt data 1 is key file 1, then, according to the naming rules of the key file in the Android keystore system, if the key corresponding to the old UID The file name of file 1 (that is, the current file name of key file 1 above) is 1000_USRPKEY_XX, and the file name of key file 1 corresponding to the new UID is 5514_USRPKEY_XX. That is to say, after the UID of the application is changed, the same key file Only the UID field changes in the file name of , while other fields (such as key type and key alias) do not change.

Possible implementation 1:

The key store service module can migrate the data stored in the key file named 1000_USRPKEY_XX (i.e. the above key file 1) to another new key file, the file name of the new key file is 5514_USRPKEY_XX, like this, The data stored in the key file named 1000_USRPKEY_XX is stored in the new key file, wherein the data stored in the key file may include key information required for decrypting the encrypted data.

Optionally, after the data migration is completed, the key store service module may delete the key file named 1000_USRPKEY_XX.

Possible implementation 2:

The key store service module can only change the file name of the key file 1 corresponding to the old UID from 1000_USRPKEY_XX to the file name of the key file 1 corresponding to the new UID 5514_USRPKEY_XX. In this case, the new key file is still the above key file. key file 1, but its file name has changed from 1000_USRPKEY_XX to 5514_USRPKEY_XX, and the data stored in the file has not changed.

In this way, by performing the key migration operation, after the UID of the application is changed, the corresponding key file can be found based on the file name of the key file generated by the new UID, and the encryption required for the decryption process can be obtained based on the key file. The key of the data, so as to avoid the loss of encrypted data and improve user experience.

S214. The key store service module of the terminal device 100 confirms that both the key integrity check and the file attribute check of the new key file pass.

Specifically, after performing the key migration operation, the key store service module of the terminal device 100 may perform a key integrity check and a file attribute check on the new key file, and if the key integrity check of the new key file is confirmed , and file attribute checks all pass, the key store service module confirms that the key migration is successful.

Wherein, the specific execution process of the key integrity check and the file attribute check by the key store service module can refer to the above-mentioned related content, and will not be repeated here.

In some embodiments, step S214 is optional.

In some embodiments, after the key store service module confirms that one of the key integrity check and the file attribute check of the new key file passes, it can confirm that the key migration is successful.

After the key storage service module of the terminal device 100 completes the key migration, it can send a key migration success instruction to the application package management service module. One possible implementation is the implementation described in the following steps S215-S217:

S215-S217, the key store service module of the terminal device 100 sends a key migration success instruction to the service management module, and after receiving the key migration success instruction, the service management module sends the key migration success instruction to the Android key store, After receiving the key migration success instruction, the Android key store sends the key migration success instruction to the application package management service module.

Wherein, the key migration success instruction is used to notify the application package management service module that the key store service module has successfully completed the key migration.

In some embodiments, step S215-step S217 are optional.

By implementing the key migration method provided by the embodiment shown in Figure 2, after the UID of the application is changed, the terminal device 100 can still display the same user interface as the user interface 100 shown in Figure 1A, that is, the terminal device 100 still saves the user's Account information (such as account name Mary, etc.) and historical data information generated during the user's use of the application, that is to say, by implementing the key migration method provided by the embodiment shown in Figure 2, the terminal device 100 determines the UID of the application After the change, the key file stored by the application on the KeyStoreService side is repaired to implement key migration, so that the application can still find the correct key file to decrypt the encrypted data after the UID is changed. Decryption, avoiding decryption failure and loss of encrypted data, improving business continuity and user experience.

The following describes another method for triggering key migration in the scenario where the PMS scans the application package provided by the embodiment of the present application.

FIG. 4 exemplarily shows the flow of a method for triggering execution of key migration in the scenario of another PMS scanning application package provided by an embodiment of the present application. As shown in FIG. 4, the method can be applied to the terminal device 100. The specific steps of the method will be described below by taking the UID change of the system application on the terminal device 100 as an example:

S401-S402, the terminal device 100 scans the application package through the PMS, and queries the new UID and the old UID of the application through Installd.

Specifically, after the terminal device 100 performs a power-on restart process (see FIG. 3E ) after the completion of the OTA or detects the operation of multi-user switching after the completion of the OTA (for example, the user's operation for option 371 in FIG. 3H ), it can trigger the PMS to scan Application package, taking the scanning system application 1 as an example, the terminal device 100 can query the new UID and old UID of the system application 1 through Installd, so as to obtain the new UID and old UID of the system application 1, wherein the new UID refers to The UID of the system application 1 after the OTA upgrade is restarted/after the multi-user switching of the OTA upgrade, and the old UID refers to the UID of the system application 1 before the OTA upgrade is restarted/before the multi-user switching of the OTA upgrade.

S403. The terminal device 100 judges whether the new UID of the application is different from the old UID.

Specifically, after acquiring the new UID and the old UID of the system application 1, the terminal device 100 can compare the new UID and the old UID of the system application 1 to determine whether the new UID and the old UID are different; 100 determines that the UID of the system application 1 has not changed, and the terminal device 100 does not perform subsequent steps; if so, the terminal device 100 determines that the UID of the system application 1 has changed. Optionally, the terminal device 100 will also determine whether the currently processed application belongs to a system application, for example, the terminal device 100 will determine whether the system application 1 belongs to a system application, and if so, the terminal device 100 will continue to perform subsequent steps.

S404. The terminal device 100 judges whether all of the calling authority check, the configuration list check, the key integrity check, and the file attribute check pass.

Specifically, if the above four checks all pass, the terminal device 100 will continue to perform subsequent steps to perform key migration; if the above four checks do not all pass, the terminal device 100 will not perform subsequent steps.

For the specific execution process of the terminal device 100 performing the above four checks, reference may be made to the relevant content in step S212 in the embodiment shown in FIG. 2 , which will not be repeated here.

S405. The terminal device 100 migrates the key file to obtain a new key file.

Wherein, for the specific execution process of step S405, reference may be made to relevant content in step S213 in the embodiment shown in FIG. 2 , which will not be repeated here.

S406-S409. The terminal device 100 judges whether the key integrity check and the file attribute check of the new key file pass? If yes, the terminal device 100 confirms that the key migration is successful; if not, the terminal device 100 deletes the new key file, and confirms that the key migration fails.

Specifically, after the terminal device 100 migrates the key file and obtains the new key file, it can perform a key integrity check and a file attribute check on the new key file. If both checks pass, the terminal device 100 can confirm that The key migration is successful. If the two checks do not pass, the terminal device 100 may delete the new key file and confirm that the key migration fails.

For the specific execution process of the key integrity check and file attribute check performed by the terminal device 100, reference may be made to the relevant content in the embodiment shown in FIG. 2 , which will not be repeated here.

The following describes a key migration method that is triggered and executed in a scenario where an application needs to obtain a key during startup and running provided by the embodiment of the present application.

Fig. 5 exemplarily shows a process of triggering execution of a key migration method in a scenario where an application needs to obtain a key during start-up and running provided by an embodiment of the present application. As shown in FIG. 5, the method can be applied to a terminal device 100, wherein the terminal device 100 can include: an application 1 (APP1), an Android keystore (AndroidKeystore), a keystore service module (KeyStoreService), a service management module ( ServiceManager), Installd.

The terminal device 100 can obtain the new UID and the old UID of the application. When it is determined that the new UID and the old UID are different, the terminal device 100 can perform key migration again, so as to ensure that the application can still decrypt data after changing the UID. Find the correct key file to decrypt the encrypted data, avoiding decryption failure and loss of encrypted data.

Exemplarily, a possible implementation manner for the terminal device 100 to obtain the new UID and old UID of the application may be the implementation described in the following phase 1 (step S501-step S509), and the specific execution process of phase 1 will be introduced in detail below :

Phase 1 (step S501-step S509): Obtaining the old and new UID phase

First, the application 1 of the terminal device 100 can send a request to obtain a key to the key store service module, and a possible implementation is the implementation described in the following steps S501-S503:

S501-S503, after the terminal device 100 detects that the application 1 is started and running, the application 1 of the terminal device 100 sends a request to obtain the key 1 to the Android keystore, and the request carries the new UID and the key alias of the key 1 , key type and other information, after receiving the request to obtain the key 1, the Android keystore sends the request to the keystore service module.

Specifically, taking application 1 as a system application as an example, after detecting that application 1 is started and running, terminal device 100 can detect that application 1 needs to acquire key 1, and then application 1 can send the acquisition key to the Android keystore 1, the request carries information such as the new UID, the key alias of key 1, and the key type, among which, key 1 is the key required to decrypt the encrypted data in application 1, and the new UID is the current key of application 1. UID. After receiving the request for obtaining the key 1 sent by the application 1, the Android key store may send the request for obtaining the key 1 to the key store service module.

S504. The key store service module of the terminal device 100 queries the package name of the application corresponding to the key alias of key 1, and determines that there is an application package name corresponding to the key alias of key 1.

Specifically, after the key store service module of the terminal device 100 receives the request for obtaining key 1 sent by the Android key store, it can query the key 1 in the configuration list based on the key alias of the key 1 carried in the request. The package name of the application corresponding to the key alias of key 1, wherein the mapping relationship between the key alias and the package name of the application is stored in the configuration list. Further, the key store service module can determine that the package name of the application corresponding to the key alias of key 1 exists in the configuration list according to the above mapping relationship, and further, the key store service module can determine the key alias of key 1 The package name of the application corresponding to the alias is the package name of application 1.

In some embodiments, the request for obtaining the key 1 may also carry the package name of the application 1. In this case, step S504 may not be performed.

S505. The key store service module of the terminal device 100 generates file name 1 based on the new UID, key alias, and key type, and confirms that the key file corresponding to file name 1 does not exist.

Specifically, the key store service module of the terminal device 100 may encode and generate the file name 1 based on the new UID carried in the request for acquiring the key 1, the key alias of the key 1, and the key type of the key 1, and further Specifically, the key store service module may search for the key file corresponding to the file name 1, and if it is confirmed that the key file corresponding to the file name 1 does not exist, the key store service module may continue to perform subsequent steps.

It should be noted that, the embodiment of the present application does not limit the time sequence of executing step S504 and step S505.

Further, the key store service module of the terminal device 100 may send a request to Installd to query the old UID, and a possible implementation is the implementation described in the following steps S506-S507:

S506-S507, the key store service module of the terminal device 100 sends a request for querying the old UID to the service management module, the request carries information such as the package name of the application corresponding to the key alias of key 1, and the service management module receives After the request for querying the old UID, send the request for querying the old UID to Installd.

Specifically, after the key store service module of the terminal device 100 determines that there is an application package name corresponding to the key alias of key 1 and that there is no key file corresponding to the above-mentioned file name 1, it may send a request to the service management module Send a request to query the old UID, which carries information such as the package name of the application corresponding to the key alias of key 1 (that is, the package name of application 1), where the old UID is the initial UID of application 1 (that is, changed to UID before the new UID). After receiving the request for querying the old UID, the service management module may send a request for querying the old UID to Installd, where the request is used to instruct Installd to query the old UID of the application 1 .

Wherein, the service management module transparently transmits the request for querying the old UID to Installd through the binder.

Further, after the Installd of the terminal device 100 receives the request for querying the old UID, it can send the old UID to the key store service system. One possible implementation is the implementation described in the following steps S508-S509:

S508-S509, Installd of the terminal device 100 sends the old UID to the service management module, and the service management module sends the old UID to the key store service module after receiving the old UID sent by Installd.

Specifically, after the Installd of the terminal device 100 receives the request for querying the old UID sent by the service management module, it can query the old UID of the application 1. After the Installd queries the old UID of the application 1, the Installd can send the application to the service management module. 1, the service management module may send the old UID of application 1 to the keystore service module after receiving the old UID of application 1 sent by Installd.

Phase 2 (step S510-step S517): key migration phase

S510, the key store service module of the terminal device 100 determines the UID change of the application 1 based on the new UID and the old UID.

Specifically, after receiving the old UID of application 1 sent by the service management module, the key store service module of the terminal device 100 can compare the old UID of application 1 with the new UID of application 1, and determine the old UID and new UID Whether they are the same, if they are the same, the key store service module determines that the UID of application 1 has not changed, and the key store service module does not perform subsequent steps; if not, the key store service module determines that the UID of application 1 has changed, optional Specifically, the key store service module will also determine whether the current application belongs to the system application, for example, the key store service module will determine whether the application 1 belongs to the system application, and if so, the key store service module will continue to perform subsequent steps.

S511. The key store service module of the terminal device 100 generates a file name 2 based on the old UID, key alias, and key type, and confirms that a key file corresponding to the file name 2 exists.

Specifically, the key store service module of the terminal device 100 may encode the key based on the received old UID of the application 1, the key alias of the key 1 carried in the request for obtaining the key 1, and the key type of the key 1 The file name 2 is generated. Further, the key store service module can search for the key file corresponding to the file name 2. If it is confirmed that the key file corresponding to the file name 2 exists, the key store service module can continue to perform subsequent steps.

S512. The key store service module of the terminal device 100 confirms that the calling authority check, the configuration list check, the key integrity check, and the file attribute check all pass.

Specifically, after the key store service module of the terminal device 100 determines that the UID of application 1 has changed and that the key file corresponding to the above-mentioned file name 2 exists, it may first perform call permission check, configuration list check, and key integrity check. . Checking the file attributes. After confirming that the above four checks are all passed, the key store service module performs subsequent steps.

Among them, the specific process of the key store service module performing the above four checks is as follows:

Configuration list check: The key store service module determines whether the package name of application 1 allows key migration based on the configuration information corresponding to the package name of application 1 recorded in the configuration list, and if so, the key store service module confirms the configuration list inspection passed.

Key integrity check: The key store service module verifies the integrity of the key by calling KeymasterTA to prevent the key from being tampered with. If the verification is successful, the key store service module confirms that the key integrity check of the key file corresponding to the above file name 2 passes.

File attribute check: The key store service module checks the attribute group and permissions of the key file corresponding to the above file name 2 by calling Installd to eliminate the potential hidden danger of the key being illegally operated.

In some embodiments, step S512 is optional.

S513. The key store service module of the terminal device 100 performs a key migration operation to obtain a new key file.

Specifically, after confirming that the call authority check, configuration list check, key integrity check, and file attribute check all pass, the key store service module of the terminal device 100 can start to perform the key migration operation, that is, the corresponding file name 2 The key file is migrated to get a new key file.

Among them, the key migration operation performed by the key store service module may include but not limited to the following two possible implementations:

Possible implementation 1:

The key store service module can migrate the data stored in the key file corresponding to the aforementioned file name 2 to another new key file, and the file name of the new key file is the aforementioned key based on the new UID and key 1 Alias, the file name 1 generated by the key type of key 1, so that the data stored in the key file corresponding to the previous file name 2 is stored in the new key file.

Optionally, after the data migration is completed, the key store service module may delete the key file corresponding to the aforementioned file name 2.

Possible implementation 2:

The key store service module can only change the file name of the key file corresponding to the aforementioned file name 2 from file name 2 to file name 1. In this case, the new key file is still the key corresponding to the aforementioned file name 2 file, but its file name has changed from file name 2 to file name 1, and the data stored in the file has not changed.

S514. The key store service module of the terminal device 100 confirms that both the key integrity check and the file attribute check of the new key file pass.

In some embodiments, step S514 is optional.

Further, after the key store service module of the terminal device 100 confirms that the key migration is successful, it can send the new key file to the application 1. One possible implementation is the implementation described in the following steps S515-S517:

S515-S517. The key store service module of the terminal device 100 sends a new key file to the Android key store. After receiving the new key file, the Android key store sends the new key file to Application 1, and Application 1 receives it. After the new key file is obtained, key 1 is obtained based on the new key file.

Specifically, after the key migration is successful, the key store service module of the terminal device 100 can send a new key file to the Android key store, and the new key file is the key file corresponding to the file name 1 after the key migration , after receiving the new key file, the Android keystore can send the new key file to application 1, and after receiving the new key file, application 1 can obtain the new key file based on the data stored in the new key file To the key 1, the encrypted data can be decrypted using the key 1. In this way, the phenomenon of loss of encrypted data and failure of decryption is avoided, and user experience is improved.

The following introduces another method for key migration triggered by an application that needs to obtain a key during startup and running provided by the embodiment of the present application.

FIG. 6 exemplarily shows the flow of another method for triggering execution of key migration in a scenario where an application needs to obtain a key during startup and operation provided by an embodiment of the present application. As shown in FIG. 6, the method can be applied to the terminal device 100. The specific steps of the method are described below by taking the UID change of the system application on the terminal device 100 as an example:

S601. The terminal device 100 determines that the key 1 needs to be acquired.

Specifically, taking Application 1 as a system application as an example, after detecting that Application 1 is started and running, terminal device 100 may determine that Key 1 needs to be obtained, where Key 1 is the encryption key required to decrypt the encrypted data in Application 1. key.

S602. The terminal device 100 determines by querying the configuration list that the package name of the application corresponding to the key alias of the key 1 exists and is the package name of the application 1.

Wherein, for the specific execution process of step S602, reference may be made to the relevant content in step S504 in the embodiment shown in FIG. 5 , which will not be repeated here.

S603. The terminal device 100 acquires the new UID and the old UID of the application 1.

Wherein, the new UID of application 1 may be obtained by terminal device 100 through application 1, and the old UID of application 1 may be obtained by terminal device 100 through Installd.

S604. The terminal device 100 judges whether the new UID and the old UID of the application 1 are different, and whether the key file required for obtaining the key 1 exists.

Specifically, the terminal device 100 may determine whether the new UID of the application 1 is different from the old UID, and if they are different, the terminal device 100 determines that the UID of the application 1 has changed. Further, the terminal device 100 can also determine whether the key file required to obtain the key 1 exists, specifically: the terminal device 100 can generate the file name 1 based on the new UID, the key alias of the key 1, and the key type, And according to the file name 1, the key file required to obtain the key 1 cannot be queried. Further, the terminal device 100 can also generate the file name 2 based on the old UID, the key alias of the key 1, and the key type, and According to the file name 2, the key file required for obtaining the key 1 is queried, and if it can be found, the terminal device 100 determines that the key file required for obtaining the key 1 exists.

After the terminal device 100 determines that the new UID of the application 1 is different from the old UID, and the key file required to obtain the key 1 exists, the terminal device 100 may continue to perform the subsequent steps, otherwise, the subsequent steps will not be performed.

S605. The terminal device 100 judges whether all of the calling authority check, the configuration list check, the key integrity check, and the file attribute check pass.

Wherein, for the specific execution process of step S605, reference may be made to the relevant content in step S512 in the embodiment shown in FIG. 5 , which will not be repeated here.

S606. The terminal device 100 migrates the key file to obtain a new key file.

Wherein, for the specific execution process of step S606, reference may be made to the relevant content in step S513 in the embodiment shown in FIG. 5 , which will not be repeated here.

S607-S610. The terminal device 100 judges whether the key integrity check and the file attribute check of the new key file pass? If so, the terminal device 100 confirms that the key migration is successful, and obtains the key 1, if not, the terminal device 100 deletes the new key file, and confirms that the key migration fails.

Specifically, after the terminal device 100 migrates the key file and obtains the new key file, it can perform a key integrity check and a file attribute check on the new key file. If both checks pass, the terminal device 100 can confirm that If the key migration is successful, the terminal device 100 can obtain the key 1 based on the new key file, so that the encrypted data can be decrypted using the key 1. If the two checks do not pass, the terminal device 100 can delete the new key file , and confirm that the key migration fails, the terminal device 100 cannot use the key 1 to decrypt the encrypted data.

For the specific execution process of the terminal device 100 performing the key integrity check and the file attribute check, reference may be made to the relevant content in the embodiment shown in FIG. 5 , and details are not repeated here.

From the embodiments shown in Figures 4-6, it can be seen that by implementing the key migration method provided by this application, when the UID of the application is changed, the terminal device 100 can be restarted after the OTA is completed/multi-user switching trigger The PMS scans the application package phase, or the key acquisition phase is required during the startup and running of the application to repair the key file stored by the application on the KeyStoreService side and implement key migration, so that the application can still be used after the UID is changed. Find the correct key file to decrypt the encrypted data, avoid decryption failure and loss of encrypted data, improve the fault tolerance of the key migration, improve user experience, and, before and after the key migration, the terminal device 100 will The file is checked for key integrity and file attributes to ensure that the entire key migration process is credible.

In this embodiment of the application, the first application may refer to system application 1 or application 1, the first UID may refer to the old UID, the second UID may refer to the new UID, and the first key file may refer to the old key file , the second key file may refer to a new key file, the first service may refer to displaying a user interface as shown in Figure 1A (i.e. the first user interface), and user data may refer to user account information, user application For historical data information generated during the process, the first user may refer to the owner shown in FIG. 3G , and the second user may be user 1 shown in FIG. 3G .

The structure of a terminal device 100 provided in the embodiment of the present application is introduced below.

FIG. 7 exemplarily shows the structure of a terminal device 100 provided in the embodiment of the present application.

As shown in Figure 7, the terminal device 100 may include: a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (universal serial bus, USB) interface 130, a charging management module 140, a power management module 141, a battery 142, antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, audio module 170, speaker 170A, receiver 170B, microphone 170C, earphone interface 170D, sensor module 180, button 190, motor 191, indicator 192, camera 193, a display screen 194, and a subscriber identification module (subscriber identification module, SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, bone conduction sensor 180M, etc.

It can be understood that, the structure shown in the embodiment of the present invention does not constitute a specific limitation on the terminal device 100 . In other embodiments of the present application, the terminal device 100 may include more or fewer components than shown in the figure, or combine certain components, or separate certain components, or arrange different components. The illustrated components can be realized in hardware, software or a combination of software and hardware.

The processor 110 may include one or more processing units, for example: the processor 110 may include an application processor (application processor, AP), a modem processor, a graphics processing unit (graphics processing unit, GPU), an image signal processor (image signal processor, ISP), controller, memory, video codec, digital signal processor (digital signal processor, DSP), baseband processor, and/or neural network processor (neural-network processing unit, NPU) wait. Wherein, different processing units may be independent devices, or may be integrated in one or more processors.

Wherein, the controller may be the nerve center and command center of the terminal device 100 . The controller can generate an operation control signal according to the instruction opcode and timing signal, and complete the control of fetching and executing the instruction.

A memory may also be provided in the processor 110 for storing instructions and data. In some embodiments, the memory in processor 110 is a cache memory. The memory may hold instructions or data that the processor 110 has just used or recycled. If the processor 110 needs to use the instruction or data again, it can be directly called from the memory. Repeated access is avoided, and the waiting time of the processor 110 is reduced, thereby improving the efficiency of the system.

In some embodiments, processor 110 may include one or more interfaces. The interface may include an integrated circuit (inter-integrated circuit, I2C) interface, an integrated circuit built-in audio (inter-integrated circuit sound, I2S) interface, a pulse code modulation (pulse code modulation, PCM) interface, a universal asynchronous transmitter (universal asynchronous receiver/transmitter, UART) interface, mobile industry processor interface (mobile industry processor interface, MIPI), general-purpose input and output (general-purpose input/output, GPIO) interface, subscriber identity module (subscriber identity module, SIM) interface, and /or universal serial bus (universal serial bus, USB) interface, etc.

The I2C interface is a bidirectional synchronous serial bus, including a serial data line (serial data line, SDA) and a serial clock line (derail clock line, SCL). In some embodiments, processor 110 may include multiple sets of I2C buses. The processor 110 can be respectively coupled to the touch sensor 180K, the charger, the flashlight, the camera 193 and the like through different I2C bus interfaces. For example, the processor 110 may be coupled to the touch sensor 180K through an I2C interface, so that the processor 110 communicates with the touch sensor 180K through an I2C bus interface to realize the touch function of the terminal device 100 .

The I2S interface can be used for audio communication. In some embodiments, processor 110 may include multiple sets of I2S buses. The processor 110 may be coupled to the audio module 170 through an I2S bus to implement communication between the processor 110 and the audio module 170 . In some embodiments, the audio module 170 can transmit audio signals to the wireless communication module 160 through the I2S interface, so as to realize the function of answering calls through the Bluetooth headset.

The PCM interface can also be used for audio communication, sampling, quantizing and encoding the analog signal. In some embodiments, the audio module 170 and the wireless communication module 160 may be coupled through a PCM bus interface. In some embodiments, the audio module 170 can also transmit audio signals to the wireless communication module 160 through the PCM interface, so as to realize the function of answering calls through the Bluetooth headset. Both I2S interface and PCM interface can be used for audio communication.

The UART interface is a universal serial data bus used for asynchronous communication. The bus can be a bidirectional communication bus. It converts the data to be transmitted between serial communication and parallel communication. In some embodiments, a UART interface is generally used to connect the processor 110 and the wireless communication module 160 . For example: the processor 110 communicates with the Bluetooth module in the wireless communication module 160 through the UART interface to realize the Bluetooth function. In some embodiments, the audio module 170 can transmit audio signals to the wireless communication module 160 through the UART interface, so as to realize the function of playing music through the Bluetooth headset.

The MIPI interface can be used to connect the processor 110 with peripheral devices such as the display screen 194 and the camera 193 . MIPI interface includes camera serial interface (camera serial interface, CSI), display serial interface (display serial interface, DSI), etc. In some embodiments, the processor 110 communicates with the camera 193 through a CSI interface to realize the shooting function of the terminal device 100 . The processor 110 communicates with the display screen 194 through the DSI interface to realize the display function of the terminal device 100 .

The GPIO interface can be configured by software. The GPIO interface can be configured as a control signal or as a data signal. In some embodiments, the GPIO interface can be used to connect the processor 110 with the camera 193 , the display screen 194 , the wireless communication module 160 , the audio module 170 , the sensor module 180 and so on. The GPIO interface can also be configured as an I2C interface, I2S interface, UART interface, MIPI interface, etc.

The USB interface 130 is an interface conforming to the USB standard specification, specifically, it can be a Mini USB interface, a Micro USB interface, a USB Type C interface, and the like. The USB interface 130 can be used to connect a charger to charge the terminal device 100, and can also be used to transmit data between the terminal device 100 and peripheral devices. It can also be used to connect headphones and play audio through them. This interface can also be used to connect other terminal devices, such as AR devices.

It can be understood that the interface connection relationship between modules shown in the embodiment of the present invention is only a schematic illustration, and does not constitute a structural limitation of the terminal device 100 . In other embodiments of the present application, the terminal device 100 may also adopt different interface connection modes in the foregoing embodiments, or a combination of multiple interface connection modes.

The charging management module 140 is configured to receive a charging input from a charger. Wherein, the charger may be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 can receive charging input from the wired charger through the USB interface 130 . In some wireless charging embodiments, the charging management module 140 may receive wireless charging input through the wireless charging coil of the terminal device 100 . While the charging management module 140 is charging the battery 142 , it can also supply power to the terminal device 100 through the power management module 141 .

The power management module 141 is used for connecting the battery 142 , the charging management module 140 and the processor 110 . The power management module 141 receives the input from the battery 142 and/or the charging management module 140 to provide power for the processor 110 , the internal memory 121 , the external memory, the display screen 194 , the camera 193 , and the wireless communication module 160 . The power management module 141 can also be used to monitor parameters such as battery capacity, battery cycle times, and battery health status (leakage, impedance). In some other embodiments, the power management module 141 may also be disposed in the processor 110 . In some other embodiments, the power management module 141 and the charging management module 140 may also be set in the same device.

The wireless communication function of the terminal device 100 may be implemented by the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, a modem processor, a baseband processor, and the like.

Antenna 1 and Antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in the terminal device 100 can be used to cover single or multiple communication frequency bands. Different antennas can also be multiplexed to improve the utilization of the antennas. For example: Antenna 1 can be multiplexed as a diversity antenna of a wireless local area network. In other embodiments, the antenna may be used in conjunction with a tuning switch.

The mobile communication module 150 can provide wireless communication solutions including 2G/3G/4G/5G applied on the terminal device 100 . The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (low noise amplifier, LNA) and the like. The mobile communication module 150 can receive electromagnetic waves through the antenna 1, filter and amplify the received electromagnetic waves, and send them to the modem processor for demodulation. The mobile communication module 150 can also amplify the signals modulated by the modem processor, and convert them into electromagnetic waves through the antenna 1 for radiation. In some embodiments, at least part of the functional modules of the mobile communication module 150 may be set in the processor 110 . In some embodiments, at least part of the functional modules of the mobile communication module 150 and at least part of the modules of the processor 110 may be set in the same device.

A modem processor may include a modulator and a demodulator. Wherein, the modulator is used for modulating the low-frequency baseband signal to be transmitted into a medium-high frequency signal. The demodulator is used to demodulate the received electromagnetic wave signal into a low frequency baseband signal. Then the demodulator sends the demodulated low-frequency baseband signal to the baseband processor for processing. The low-frequency baseband signal is passed to the application processor after being processed by the baseband processor. The application processor outputs sound signals through audio equipment (not limited to speaker 170A, receiver 170B, etc.), or displays images or videos through display screen 194 . In some embodiments, the modem processor may be a stand-alone device. In some other embodiments, the modem processor may be independent from the processor 110, and be set in the same device as the mobile communication module 150 or other functional modules.

The wireless communication module 160 can provide wireless local area networks (wireless local area networks, WLAN) (such as wireless fidelity (Wireless Fidelity, Wi-Fi) network), bluetooth (bluetooth, BT), global navigation satellite, etc. System (global navigation satellite system, GNSS), frequency modulation (frequency modulation, FM), near field communication technology (near field communication, NFC), infrared technology (infrared, IR) and other wireless communication solutions. The wireless communication module 160 may be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2 , frequency-modulates and filters the electromagnetic wave signals, and sends the processed signals to the processor 110 . The wireless communication module 160 can also receive the signal to be sent from the processor 110 , frequency-modulate it, amplify it, and convert it into electromagnetic waves through the antenna 2 for radiation.

In some embodiments, the antenna 1 of the terminal device 100 is coupled to the mobile communication module 150, and the antenna 2 is coupled to the wireless communication module 160, so that the terminal device 100 can communicate with the network and other devices through wireless communication technology. Wireless communication technologies may include global system for mobile communications (GSM), general packet radio service (GPRS), code division multiple access (CDMA), broadband code division Multiple access (wideband code division multiple access, WCDMA), time-division code division multiple access (TD-SCDMA), long term evolution (LTE), BT, GNSS, WLAN, NFC, FM , and/or IR technology, etc. GNSS can include global positioning system (global positioning system, GPS), global navigation satellite system (global navigation satellite system, GLONASS), Beidou satellite navigation system (beidou navigation satellite system, BDS), quasi-zenith satellite system (quasi-zenith) satellite system (QZSS) and/or satellite based augmentation systems (SBAS).

The terminal device 100 implements a display function through a GPU, a display screen 194, an application processor, and the like. The GPU is a microprocessor for image processing, and is connected to the display screen 194 and the application processor. GPUs are used to perform mathematical and geometric calculations for graphics rendering. Processor 110 may include one or more GPUs that execute program instructions to generate or change display information.

The display screen 194 is used to display images, videos and the like. The display screen 194 includes a display panel. The display panel may be a liquid crystal display (LCD). The display panel can also use organic light-emitting diodes (organic light-emitting diode, OLED), active matrix organic light-emitting diodes or active-matrix organic light emitting diodes (active-matrix organic light emitting diode, AMOLED), flexible light-emitting diodes (flex light-emitting diode, FLED), miniled, microled, micro-oled, quantum dot light emitting diodes (quantum dot light emitting diodes, QLED), etc. In some embodiments, the terminal device 100 may include 1 or N display screens 194, where N is a positive integer greater than 1.

The terminal device 100 can realize the shooting function through the ISP, the camera 193 , the video codec, the GPU, the display screen 194 and the application processor.

The ISP is used for processing the data fed back by the camera 193 . For example, when taking a picture, open the shutter, the light is transmitted to the photosensitive element of the camera through the lens, and the optical signal is converted into an electrical signal, and the photosensitive element of the camera transmits the electrical signal to the ISP for processing, and converts it into an image visible to the naked eye. ISP can also perform algorithm optimization on image noise, brightness, etc. ISP can also optimize the exposure, color temperature and other parameters of the shooting scene. In some embodiments, the ISP may be located in the camera 193 .

Camera 193 is used to capture still images or video. The object generates an optical image through the lens and projects it to the photosensitive element. The photosensitive element may be a charge coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the light signal into an electrical signal, and then transmits the electrical signal to the ISP to convert it into a digital image signal. The ISP outputs the digital image signal to the DSP for processing. DSP converts digital image signals into standard RGB, YUV and other image signals. In some embodiments, the terminal device 100 may include 1 or N cameras 193, where N is a positive integer greater than 1.

Digital signal processors are used to process digital signals. In addition to digital image signals, they can also process other digital signals. For example, when the terminal device 100 selects a frequency point, the digital signal processor is used to perform Fourier transform on the energy of the frequency point.

Video codecs are used to compress or decompress digital video. The terminal device 100 may support one or more video codecs. In this way, the terminal device 100 can play or record videos in various encoding formats, for example: moving picture experts group (moving picture experts group, MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

The NPU is a neural-network (NN) computing processor. By referring to the structure of biological neural networks, such as the transfer mode between neurons in the human brain, it can quickly process input information and continuously learn by itself. Applications such as intelligent cognition of the terminal device 100 can be implemented through the NPU, such as image recognition, face recognition, speech recognition, text understanding, and the like.

The external memory interface 120 may be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the terminal device 100. The external memory card communicates with the processor 110 through the external memory interface 120 to implement a data storage function. Such as saving music, video and other files in the external memory card.

The internal memory 121 may be used to store computer-executable program codes including instructions. The processor 110 executes various functional applications and data processing of the terminal device 100 by executing instructions stored in the internal memory 121 . The internal memory 121 may include an area for storing programs and an area for storing data. Wherein, the stored program area can store an operating system, at least one application program required by a function (such as a sound playing function, an image playing function, etc.) and the like. The storage data area can store data created during the use of the terminal device 100 (such as audio data, phonebook, etc.) and the like. In addition, the internal memory 121 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one magnetic disk storage device, flash memory device, universal flash storage (universal flash storage, UFS) and the like.

The terminal device 100 may implement an audio function through an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, and an application processor. Such as music playback, recording, etc.

The audio module 170 is used to convert digital audio information into analog audio signal output, and is also used to convert analog audio input into digital audio signal. The audio module 170 may also be used to encode and decode audio signals. In some embodiments, the audio module 170 may be set in the processor 110 , or some functional modules of the audio module 170 may be set in the processor 110 .

Speaker 170A, also referred to as a "horn", is used to convert audio electrical signals into sound signals. The terminal device 100 can listen to music through the speaker 170A, or listen to hands-free calls.

Receiver 170B, also called "earpiece", is used to convert audio electrical signals into sound signals. When the terminal device 100 receives a phone call or voice information, the receiver 170B can be placed close to the human ear to receive the voice.

The microphone 170C, also called "microphone" or "microphone", is used to convert sound signals into electrical signals. When making a phone call or sending a voice message, the user can put his mouth close to the microphone 170C to make a sound, and input the sound signal to the microphone 170C. The terminal device 100 may be provided with at least one microphone 170C. In some other embodiments, the terminal device 100 may be provided with two microphones 170C, which may also implement a noise reduction function in addition to collecting sound signals. In some other embodiments, the terminal device 100 can also be provided with three, four or more microphones 170C to realize sound signal collection, noise reduction, identify sound sources, and realize directional recording functions, etc.

The earphone interface 170D is used for connecting wired earphones. The earphone interface 170D may be a USB interface 130, or a 3.5mm open mobile terminal platform (open mobile terminal platform, OMTP) standard interface, or a cellular telecommunications industry association of the USA (CTIA) standard interface.

The pressure sensor 180A is used to sense the pressure signal and convert the pressure signal into an electrical signal. In some embodiments, pressure sensor 180A may be disposed on display screen 194 . There are many types of pressure sensors 180A, such as resistive pressure sensors, inductive pressure sensors, and capacitive pressure sensors. A capacitive pressure sensor may be comprised of at least two parallel plates with conductive material. When a force is applied to the pressure sensor 180A, the capacitance between the electrodes changes. The terminal device 100 determines the intensity of pressure according to the change in capacitance. When a touch operation acts on the display screen 194, the terminal device 100 detects the intensity of the touch operation according to the pressure sensor 180A. The terminal device 100 may also calculate the touched position according to the detection signal of the pressure sensor 180A. In some embodiments, touch operations acting on the same touch position but with different touch operation intensities may correspond to different operation instructions. For example: when there is a touch operation with a touch operation intensity less than the first pressure threshold acting on the short message application icon, execute the instruction of viewing the short message. When a touch operation whose intensity is greater than or equal to the first pressure threshold acts on the icon of the short message application, the instruction of creating a new short message is executed.

The gyroscope sensor 180B can be used to determine the motion posture of the terminal device 100 . In some embodiments, the angular velocity of the terminal device 100 around three axes (ie, x, y and z axes) can be determined by the gyro sensor 180B. The gyro sensor 180B can be used for image stabilization. Exemplarily, when the shutter is pressed, the gyro sensor 180B detects the shaking angle of the terminal device 100, calculates the distance that the lens module needs to compensate according to the angle, and allows the lens to counteract the shaking of the terminal device 100 through reverse motion to achieve anti-shake. The gyro sensor 180B can also be used for navigation and somatosensory game scenes.

The air pressure sensor 180C is used to measure air pressure. In some embodiments, the terminal device 100 calculates the altitude based on the air pressure value measured by the air pressure sensor 180C to assist positioning and navigation.

The magnetic sensor 180D includes a Hall sensor. The terminal device 100 may use the magnetic sensor 180D to detect the opening and closing of the flip holster. In some embodiments, when the terminal device 100 is a clamshell machine, the terminal device 100 may detect opening and closing of the clamshell according to the magnetic sensor 180D. Furthermore, according to the detected opening and closing state of the leather case or the opening and closing state of the flip cover, features such as automatic unlocking of the flip cover are set.

The acceleration sensor 180E can detect the acceleration of the terminal device 100 in various directions (generally three axes). When the terminal device 100 is stationary, the magnitude and direction of gravity can be detected. It can also be used to identify the posture of the terminal device 100, and can be applied to applications such as horizontal and vertical screen switching, pedometers, etc.

The distance sensor 180F is used to measure the distance. The terminal device 100 can measure the distance by infrared or laser. In some embodiments, when shooting a scene, the terminal device 100 may use the distance sensor 180F for distance measurement to achieve fast focusing.

Proximity light sensor 180G may include, for example, light emitting diodes (LEDs) and light detectors, such as photodiodes. The light emitting diodes may be infrared light emitting diodes. The terminal device 100 emits infrared light through the light emitting diode. The terminal device 100 detects infrared reflected light from nearby objects using a photodiode. When sufficient reflected light is detected, it can be determined that there is an object near the terminal device 100 . When insufficient reflected light is detected, the terminal device 100 may determine that there is no object near the terminal device 100 . The terminal device 100 can use the proximity light sensor 180G to detect that the user holds the terminal device 100 close to the ear to make a call, so as to automatically turn off the screen to save power. The proximity light sensor 180G can also be used in leather case mode, automatic unlock and lock screen in pocket mode.

The ambient light sensor 180L is used for sensing ambient light brightness. The terminal device 100 can adaptively adjust the brightness of the display screen 194 according to the perceived ambient light brightness. The ambient light sensor 180L can also be used to automatically adjust the white balance when taking pictures. The ambient light sensor 180L can also cooperate with the proximity light sensor 180G to detect whether the terminal device 100 is in the pocket to prevent accidental touch.

The fingerprint sensor 180H is used to collect fingerprints. The terminal device 100 can use the collected fingerprint characteristics to realize fingerprint unlocking, access to the application lock, take pictures with fingerprints, answer incoming calls with fingerprints, and so on.

The temperature sensor 180J is used to detect temperature. In some embodiments, the terminal device 100 uses the temperature detected by the temperature sensor 180J to implement a temperature processing strategy. For example, when the temperature reported by the temperature sensor 180J exceeds the threshold, the terminal device 100 may reduce the performance of a processor located near the temperature sensor 180J, so as to reduce power consumption and implement thermal protection. In some other embodiments, when the temperature is lower than another threshold, the terminal device 100 heats the battery 142 to avoid abnormal shutdown of the terminal device 100 caused by the low temperature. In some other embodiments, when the temperature is lower than another threshold, the terminal device 100 boosts the output voltage of the battery 142 to avoid abnormal shutdown caused by low temperature.

Touch sensor 180K, also known as "touch panel". The touch sensor 180K can be disposed on the display screen 194, and the touch sensor 180K and the display screen 194 form a touch screen, also called a “touch screen”. The touch sensor 180K is used to detect a touch operation on or near it. The touch sensor can pass the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through the display screen 194 . In other embodiments, the touch sensor 180K may also be disposed on the surface of the terminal device 100 , which is different from the position of the display screen 194 .

The bone conduction sensor 180M can acquire vibration signals. In some embodiments, the bone conduction sensor 180M can acquire the vibration signal of the vibrating bone mass of the human voice. The bone conduction sensor 180M can also contact the human pulse and receive the blood pressure beating signal. In some embodiments, the bone conduction sensor 180M can also be disposed in the earphone, combined into a bone conduction earphone. The audio module 170 can analyze the voice signal based on the vibration signal of the vibrating bone mass of the vocal part acquired by the bone conduction sensor 180M, so as to realize the voice function. The application processor can analyze the heart rate information based on the blood pressure beating signal acquired by the bone conduction sensor 180M, so as to realize the heart rate detection function.

The keys 190 include a power key, a volume key and the like. The key 190 may be a mechanical key. It can also be a touch button. The terminal device 100 may receive key input and generate key signal input related to user settings and function control of the terminal device 100 .

The motor 191 can generate a vibrating reminder. The motor 191 can be used for incoming call vibration prompts, and can also be used for touch vibration feedback. For example, touch operations applied to different applications (such as taking pictures, playing audio, etc.) may correspond to different vibration feedback effects. The motor 191 may also correspond to different vibration feedback effects for touch operations acting on different areas of the display screen 194 . Different application scenarios (for example: time reminder, receiving information, alarm clock, games, etc.) can also correspond to different vibration feedback effects. The touch vibration feedback effect can also support customization.

The indicator 192 can be an indicator light, and can be used to indicate charging status, power change, and can also be used to indicate messages, missed calls, notifications, and the like.

The SIM card interface 195 is used for connecting a SIM card. The SIM card can be connected and separated from the terminal device 100 by inserting it into the SIM card interface 195 or pulling it out from the SIM card interface 195 . The terminal device 100 may support 1 or N SIM card interfaces, where N is a positive integer greater than 1. SIM card interface 195 can support Nano SIM card, Micro SIM card, SIM card etc. Multiple cards can be inserted into the same SIM card interface 195 at the same time. The types of multiple cards may be the same or different. The SIM card interface 195 is also compatible with different types of SIM cards. The SIM card interface 195 is also compatible with external memory cards. The terminal device 100 interacts with the network through the SIM card to implement functions such as calling and data communication. In some embodiments, the terminal device 100 adopts an eSIM, that is, an embedded SIM card. The eSIM card can be embedded in the terminal device 100 and cannot be separated from the terminal device 100 .

It should be understood that the terminal device 100 shown in FIG. 7 is only an example, and the terminal device 100 may have more or fewer components than those shown in FIG. 7, two or more components may be combined, or Different component configurations are possible. The various components shown in Figure 7 may be implemented in hardware, software, or a combination of hardware and software including one or more signal processing and/or application specific integrated circuits.

The software structure of a terminal device 100 provided in the embodiment of the present application is introduced below.

FIG. 8 exemplarily shows a software structure of a terminal device 100 provided in the embodiment of the present application.

As shown in FIG. 8 , the software system of the terminal device 100 may adopt a layered architecture, an event-driven architecture, a micro-kernel architecture, a micro-service architecture, or a cloud architecture. In this embodiment of the present application, an Android system with a layered architecture is taken as an example to illustrate the software structure of the terminal device 100 .

The layered architecture divides the software into several layers, and each layer has a clear role and division of labor. Layers communicate through software interfaces. In some embodiments, the Android system is divided into four layers, which are respectively the application program layer, the application program framework layer, the Android runtime (Android runtime) and the system library, and the kernel layer from top to bottom.

The application layer can consist of a series of application packages.

As shown in FIG. 8, the application package may include applications such as camera, gallery, calendar, call, map, clock, WLAN, Bluetooth, music, video, and short message.

The application framework layer provides an application programming interface (application programming interface, API) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

As shown in Figure 8, the application framework layer can include window manager, content provider, view system, phone manager, resource manager, notification manager, etc.

A window manager is used to manage window programs. The window manager can get the size of the display screen, determine whether there is a status bar, lock the screen, capture the screen, etc.

Content providers are used to store and retrieve data and make it accessible to applications. Said data may include video, images, audio, calls made and received, browsing history and bookmarks, phonebook, etc.

The view system includes visual controls, such as controls for displaying text, controls for displaying pictures, and so on. The view system can be used to build applications. A display interface can consist of one or more views. For example, a display interface including a text message notification icon may include a view for displaying text and a view for displaying pictures.

The phone manager is used to provide the communication function of the terminal device 100 . For example, the management of call status (including connected, hung up, etc.).

The resource manager provides various resources for the application, such as localized strings, icons, pictures, layout files, video files, and so on.

The notification manager enables the application to display notification information in the status bar, which can be used to convey notification-type messages, and can automatically disappear after a short stay without user interaction. For example, the notification manager is used to notify the download completion, message reminder, etc. The notification manager can also be a notification that appears on the top status bar of the system in the form of a chart or scroll bar text, such as a notification of an application running in the background, or a notification that appears on the screen in the form of a dialog window. For example, prompting text information in the status bar, issuing a prompt sound, vibrating the electronic device, and flashing the indicator light, etc.

In the embodiment of the present application, the application framework layer can also include the following modules: Android Keystore (AndroidKeystore), application package management service module (PMS), service management module (ServiceManager), and Installer module. For the functions and working details, reference may be made to relevant content in the above-mentioned embodiments, and details are not repeated here.

Android Runtime includes core library and virtual machine. The Android runtime is responsible for the scheduling and management of the Android system.

The core library consists of two parts: one part is the function function that the java language needs to call, and the other part is the core library of Android.

The application layer and the application framework layer run in virtual machines. The virtual machine executes the java files of the application program layer and the application program framework layer as binary files. The virtual machine is used to perform functions such as object life cycle management, stack management, thread management, security and exception management, and garbage collection.

A system library can include multiple function modules. For example: surface manager (surface manager), media library (Media Libraries), 3D graphics processing library (eg: OpenGL ES), 2D graphics engine (eg: SGL), etc.

The surface manager is used to manage the display subsystem and provides the fusion of 2D and 3D layers for multiple applications.

The media library supports playback and recording of various commonly used audio and video formats, as well as still image files, etc. The media library can support a variety of audio and video encoding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.

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

2D graphics engine is a drawing engine for 2D drawing.

In the embodiment of the present application, the following modules can also be included in the system library: Installd module, key store service module (KeyStoreService), wherein, the specific functions and working details of these two modules can refer to the relevant content in the foregoing embodiments , which will not be repeated here.

The kernel layer is the layer between hardware and software. The kernel layer includes at least a display driver, a camera driver, a Bluetooth driver, and a sensor driver.

The workflow of the software and hardware of the terminal device 100 will be exemplarily described below in conjunction with capturing and photographing scenes.

When the touch sensor 180K receives a touch operation, a corresponding hardware interrupt is sent to the kernel layer. The kernel layer processes touch operations into original input events (including touch coordinates, time stamps of touch operations, and other information). Raw input events are stored at the kernel level. The application framework layer obtains the original input event from the kernel layer, and identifies the control corresponding to the input event. Take the touch operation as a touch click operation, and the control corresponding to the click operation is the control of the camera application icon as an example. The camera application calls the interface of the application framework layer to start the camera application, and then starts the camera driver by calling the kernel layer. Camera 193 captures still images or video.

In the above embodiments, all or part of them may be implemented by software, hardware, firmware or any combination thereof. When implemented using software, it may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on the computer, the processes or functions according to the present application will be generated in whole or in part. The computer can be a general purpose computer, a special purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from a website, computer, server or data center Transmission to another website site, computer, server, or data center by wired (eg, coaxial cable, optical fiber, DSL) or wireless (eg, infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that can be accessed by a computer, or a data storage device such as a server or a data center integrated with one or more available media. The available medium may be a magnetic medium (such as a floppy disk, a hard disk, or a magnetic tape), an optical medium (such as a DVD), or a semiconductor medium (such as a solid state disk (solid state disk, SSD)), etc.

Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments are realized. The processes can be completed by computer programs to instruct related hardware. The programs can be stored in computer-readable storage media. When the programs are executed , may include the processes of the foregoing method embodiments. The aforementioned storage medium includes: ROM or random access memory RAM, magnetic disk or optical disk, and other various media that can store program codes.

The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: it can still apply to the foregoing embodiments Modifications are made to the recorded technical solutions, or equivalent replacements are made to some of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of each embodiment of the application.

Claims

A key management method, applied to a terminal device, the terminal device is installed with a first application, characterized in that the method includes:

The terminal device changes the user identification UID of the first application from the first UID to a second UID, and the first application accesses the first key file according to the UID of the first application, and the The data stored in the first key file is required for the first application to execute the first service, and the file name of the first key file is generated by the terminal device based on the first UID;

The terminal device generates a second key file based on the first key file;

Wherein, the file name of the second key file is generated by the terminal device based on the second UID, and the data stored in the second key file is the same as the data stored in the first key file .
The method according to claim 1, wherein the terminal device generates a second key file based on the first key file, specifically comprising:

The terminal device migrates the data stored in the first key file to the second key file;

or,

The terminal device generates the second key file by modifying the file name of the first key file to the file name of the second key file.
The method according to claim 1 or 2, wherein before the terminal device changes the UID of the first application from the first UID to the second UID, the method further comprises:

The terminal device restarts after completing the over-the-air upgrade OTA;

or,

After the terminal device completes the over-the-air upgrade OTA, it detects that the user logging in to the terminal device is switched from the first user to the second user.
The method according to claim 1 or 2, wherein before the terminal device changes the UID of the first application from the first UID to the second UID, the method further comprises:

The terminal device detects that the first application is started and running.
The method according to claim 3, wherein the terminal device includes an application package management service (PMS), and before the terminal device generates a second key file based on the first key file, the method further includes :

The terminal device detects through the PMS that the UID of the first application has changed from the first UID to the second UID.
The method according to claim 4, wherein the terminal device includes a key store service KeyStoreService, and before the terminal device generates a second key file based on the first key file, the method further includes :

The terminal device detects through the KeyStoreService that the UID of the first application has changed from the first UID to the second UID.
The method according to any one of claims 1-6, wherein the terminal device includes an Installd module, and before the terminal device generates a second key file based on the first key file, the method Also includes:

The terminal device queries the first UID and the second UID through the Installd module.
The method according to claims 1-7, wherein the terminal device uses the data stored in the second key file to execute the first service, specifically comprising:

The terminal device displays a first user interface, the first user interface includes user data, and the user data is obtained by using the data stored in the second key file.
The method according to claim 1-8, wherein when the UID of the first application changes from the first UID to the second UID, the system access authority of the first application changes to Low.
The method according to any one of claims 1-9, wherein after the terminal device generates a second key file based on the first key file, the method further comprises:

The terminal device saves the second key file.
The method according to any one of claims 1-10, wherein the first application is a system application, and the system application is an application preset by an operating system of the terminal device.
The method according to any one of claims 1-11, wherein the UID of the first application is generated based on a user identifier UserId and an application identifier APPId, wherein the user identifier UserId is generated by the terminal device based on The number of users logging into the terminal device is determined, and the application identifier APPId is determined by the terminal device based on the package name of the first application.
A terminal device, characterized in that the terminal device includes one or more processors and one or more memories; wherein the one or more memories are coupled to the one or more processors, and the one or more or a plurality of memories are used to store computer program codes, the computer program codes include computer instructions, and when the one or more processors execute the computer instructions, the terminal device performs any of claims 1-12 one of the methods described.
A computer storage medium, characterized in that the computer storage medium stores a computer program, the computer program includes program instructions, and when the program instructions are run on a terminal device, the terminal device is made to execute the computer program according to claim 1. - The method described in any one of 12.