CN116070222A

CN116070222A - Key migration method and related equipment

Info

Publication number: CN116070222A
Application number: CN202111279912.3A
Authority: CN
Inventors: 漆昌桂; 胡慧锋
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2021-10-29
Filing date: 2021-10-29
Publication date: 2023-05-05
Also published as: WO2023072206A1

Abstract

After determining that an application changes a UID, a terminal device can repair a key file stored on a KeyStoreService side by the application before changing the UID, namely, can realize key migration by migrating data in one stored key file into another new key file, thereby ensuring that the application can find a correct key file (namely, a new key file) when searching the key file by using a file name of the key file generated based on the changed UID after changing the UID, and can successfully decrypt encrypted data by using the correct key file, avoiding decryption failure and encrypted data loss, improving service continuity and improving user experience.

Description

Key migration method and related equipment

Technical Field

The present disclosure relates to the field of communications technologies, and in particular, to a key migration method and related devices.

Background

With the popularization of intelligent terminal equipment and the development of internet technology, some terminal equipment such as intelligent mobile phones, notebook computers and tablet computers have become indispensable products in daily life of people. In order to meet the increasing use demands of users, the variety and number of applications installed on these terminal devices are also increasing.

In general, system applications on terminal devices are granted high authority, and once these system applications are broken, security risks such as system configuration being manipulated, user data and system data being revealed are caused, and huge potential safety hazards are brought to the system. Therefore, it is necessary to change and rectify the User Identification (UID) of these system applications. Because the terminal device searches the key file according to the UID of the application, after changing the UID of the application, 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), so that the new UID application cannot decrypt the encrypted data applied by the old UID, further the encrypted data is lost, the service continuity is reduced, and the user experience is poor.

Disclosure of Invention

The embodiment of the application provides a key migration method and related equipment, which can ensure service continuity and user experience under the condition of changing an applied UID.

In a first aspect, an embodiment of the present application provides a key management method, applied to a terminal device, where the terminal device installs a first application, the method includes: the terminal equipment changes a user identification UID of a first application from a first UID to a second UID, the first application accesses a first key file according to the user identification UID of the first application, data stored in the first key file is needed to be used when the first application executes a first service, and a file name of the first key file is generated by the terminal equipment based on the first UID; the terminal equipment generates a second key file based on the first key file; the file name of the second key file is generated by the terminal equipment 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.

By implementing the method provided by the embodiment of the application, after the terminal equipment determines that the application changes the UID, the key file stored on the Key store service side by the application before changing the UID can be repaired, namely, the key migration can be realized by migrating the data in one stored key file into another new key file, so that the application can find the correct key file (namely the new key file) when searching the key file by using the file name of the key file generated based on the changed UID after changing the UID, thereby successfully decrypting the encrypted data by using the correct key file, avoiding decryption failure and encrypted data loss, improving service continuity and improving user experience.

In one possible implementation manner, the terminal device generates a second key file based on the first key file, and specifically includes: the terminal equipment 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.

Thus, when the application searches for the key file using the file name of the key file generated based on the changed UID, the correct key file can be found, and the encrypted data can be successfully decrypted using the correct key file.

In one 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: starting up and restarting the terminal equipment after finishing over-the-air upgrading OTA; or after the terminal equipment finishes the over-the-air OTA, the user logging in the terminal equipment is detected to be switched from the first user to the second user.

Thus, the terminal equipment can be triggered to execute the operation of inquiring the UID, so that whether the UID of the application is changed or not can be determined.

In one 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 equipment detects that the first application is started and operated.

In a possible implementation, 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 that the UID of the first application is changed from the first UID to the second UID through the PMS.

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

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

In this way, the terminal device can determine whether the UID of the application has been changed or not by keystore service.

In one possible implementation, the terminal device includes an instrument module, and before the terminal device generates the second key file based on the first key file, the method further includes: the terminal equipment inquires the first UID and the second UID through the Inlitald module.

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

In one possible implementation manner, the terminal device performs the first service by using the data stored in the second key file, and specifically includes: the terminal device displays a first user interface, wherein the first user interface comprises user data, and the user data is acquired by using data stored in the second key file.

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

In one possible implementation, in a case where 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 low.

In this way, the security can be improved by changing the UID to reduce the system access authority of the application.

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

Therefore, key integrity check and file authority check are carried out on the new key file, so that key tampering can be prevented, and potential hidden danger of illegal operation of the key is eliminated.

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

Therefore, by carrying out key integrity check and file authority check on the old key file, key tampering can be prevented, and potential hidden danger of illegal operation of the key is eliminated.

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

Thus, when the terminal equipment needs to acquire the key, the terminal equipment can find the key file corresponding to the key.

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

In one possible implementation, the UID of the first application is generated based on a user identifier UserId and an application identifier APPId, where the user identifier UserId is determined by the terminal device based on the number of users logged into the terminal device, and the application identifier APPId is determined by the terminal device based on the package name of the first application.

In a second aspect, embodiments of the present application provide a terminal device including one or more processors and one or more memories; wherein the one or more memories are coupled to the one or more processors, the one or more memories being operable to store computer program code comprising computer instructions that, when executed by the one or more processors, cause the terminal device to perform the method of any of the possible implementations of the first aspect described above.

In a third aspect, embodiments of the present application provide a computer storage medium storing a computer program comprising program instructions that, when run on a terminal device, cause the terminal device to perform the method of any one of the possible implementation manners of the first aspect.

In a fourth aspect, embodiments of the present application provide a computer program product which, when run on a computer, causes the computer to perform the method of any one of the possible implementations of the first aspect.

Drawings

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

fig. 2 is a flowchart of a key migration method triggered and executed in a PMS scanning application package according to an embodiment of the present application;

fig. 3A-3H are schematic diagrams of a user interface for a set of OTA upgrades and multi-user handoff provided in an embodiment of the present application;

fig. 4 is a flowchart of a key migration method triggered and executed in a scenario of another PMS scanning application package according to an embodiment of the present application;

fig. 5 is a schematic flow chart of a key migration method triggered and executed by an application in a scenario where a key needs to be acquired in a starting and running process according to an embodiment of the present application;

FIG. 6 is a flowchart of a key migration method triggered and executed by another application in a scenario where a key needs to be acquired during a startup and operation process 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 software architecture of a terminal device according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Wherein, in the description of the embodiments of the present application, "/" means or is meant unless otherwise indicated, for example, a/B may represent a or B; the text "and/or" is merely an association relation describing the associated object, and indicates that three relations may exist, for example, a and/or B may indicate: the three cases where a exists alone, a and B exist together, and B exists alone, and in addition, in the description of the embodiments of the present application, "plural" means two or more than two.

It should be understood that the terms first, second, and the like in the description and in the claims and drawings of the present application are used for distinguishing between different objects and not necessarily for describing a particular sequential or chronological order. Furthermore, the terms "comprise" and "have," as well as any variations thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, system, article, or apparatus that comprises a list of steps or elements is not limited to only those listed steps or elements but may include other steps or elements not listed or inherent to such process, method, article, or apparatus.

Reference in the specification to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the application. The appearances of such phrases 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. Those of skill in the art will explicitly and implicitly understand that the embodiments described herein may be combined with other embodiments.

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

1. Key store system (KeyStore System)

Taking an Android keystore system (Android KeyStoreSystem) as an example, the Android keystore system is a keystore management system, and program functions are provided by a KeyChain (KeyChain) application programming interface (ApplicationProgrammingInterface, API) introduced in Android 4.0 and an Android keystore introduced in Android 4.3. The android keystore system may store encryption keys in containers, thereby providing difficulty in extracting keys in the device, which after entering the keystore may be used for encryption operations, but the keying material is still not derivable. The android keystore system may protect the keying material from unauthorized use.

The android keystore system can be divided into three parts at the architecture level:

a first part: an android keystore (android keystore) is located at the Framework layer and is used to provide the relevant interfaces for key operations to the application layer.

A second part: and the key store service module (KeyStoreservice) is positioned in a Native layer and is used for managing and storing keys and corresponding to a process key.

Third section: and the Keymaster trusted application (Trusted Application, TA) runs in a trusted security environment (Trusted Execution Environment, TEE) and is used for providing the realization of related security services such as key generation, data encryption and decryption, authentication, signature verification and the like.

Some applications on the terminal device may use the android keystore system to encrypt and decrypt data, and their key files (which may also be referred to as key index files) will be stored in the data directory in the keystore service module, typically, the file names of the key files under the management of the android keystore system are generated based on encoding the UID, the key type and the 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 name is XX. The key library service module can call KeyMasterTA to carry out related encryption and decryption operations of data by taking the key file as an access for obtaining the key.

It should be noted that, the keystore system may include, but is not limited to, an android keystore system, and in this embodiment of the present application, the keystore system is merely described by taking the keystore system as an example of the android keystore system, and should not be construed as limiting the present application.

2. User Identification (UID)

For the Linux system, the multi-user system has a UID, and the UID is mapped to a user name, so that for convenience in user management, a plurality of users can be grouped into a group, and each group has a group ID (GroupIdentification, GID).

The Android system does not support multiple users before Android 4.2, and after Android 4.2, a multi-user function is added, that is, multiple users can be added on one Android device, and the user types can comprise a main user, a secondary user and a visitor user. The main user is the first user added to the equipment, and cannot be removed unless factory setting is restored, other users operate in the foreground, and the main user is always in an operating state; a secondary user is any user added to the device other than the primary user, which can be removed (either by the user itself or by the primary user) without affecting other users on the device, which can run in the background and can continue to connect to the network; the guest user is a temporary secondary user and the system provides an explicit option to delete the guest user, which can be quickly deleted when the guest user is no longer using the device, only one guest user at a time.

For the Android system, the UID is an Android application identity identifier based on a specific user, and in general, one UID corresponds to one application, and the UID of one application is created when an application package management service module (PackageManagerService, PMS) analyzes and installs an Android application package (AndroidApplicationPackage, APK) file. If the same UID is shared among a plurality of different Android applications, the same sharedUserId is required to be set in an XML file of AndroidManifest.xml, and the same signature is required.

The Android system for multiple users introduces two new concepts: a User identifier (User Id) and an application identifier (App Id).

Wherein UserId is related to the number of users (e.g., primary users, secondary users, guest users, etc.) on the terminal device. If only one User exists on the terminal equipment, namely a single User state, the User Id of the User is 0; if there are a plurality of users on the terminal device, i.e. the multi-User status, each User has its own User Id, and is different from each other, except for the default User (the User Id of the default User is 0), the User ids of other users are sequentially incremented from 10.

The App Id is related to the application on the terminal device, and even for different users, the App Id is the same for the application with the same package name (package name for short), that is, once the application is deployed, the App Id is fixed, and will not change in the normal operation process of the system.

There are two ways to determine App Id: the first way is automatic allocation by the PMS, which is generally applicable to third party applications, or, part of the system applications; the second approach is to specify Android: sharedUserId for fixed allocation in "Android management. Xml", which is generally applicable to most system applications.

The UID has the following conversion relation with User Id and App Id:

UID＝User Id*100000+App Id；

wherein, the value range of App Id is [0,100000]; for the User Id, in the single User (default User) state, the User Id is 0, in the multi-User state, the User Id of the default User is 0, if a new User, for example, user 1 is added, the User Id of User 1 is 10, if a new User, for example, user 2 is added, the User Id of User 2 is 11, if a new User, for example, user 3 is added, the User Id of User 3 is 12, and so on, that is, the User ids of other users are sequentially incremented from 10, for example, 10, 11, 12, 13, and so on, except for the default User (User Id of the default User is 0).

According to the conversion relation between the UID and the User Id, and the App Id, assuming that the App Id of a certain application is 5514, for a default User, the User Id is 0, the UID is 5514, i.e., uid=app Id; for User 1, whose User Id is 10, the UID is 1005514. That is, the UIDs of the applications are different for the same application, and it is easy to understand that UIDs can be used as identifiers to distinguish the same application from different users.

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

The PMS is responsible for managing various application packages on the system, and may be used for installing, uninstalling, updating, resolving, managing authority, etc. the application packages on the terminal device.

The action phase of the PMS is mainly concentrated in a boot phase (boot phase) of the terminal equipment and is responsible for carrying out an application package scanning process (namely a PMS package scanning process), and the process comprises five phases: a start phase (boot_progress_pms_start), a scan system (system) partition phase (boot_progress_pms_system_scan_start), a scan data (data) partition phase (boot_progress_pms_data_scan_start), a scan end phase (boot_progress_pms_scan_end), and a preparation phase (boot_progress_pms_ready).

In the beginning, many PMS objects can be created by calling the main method and assigned to member variables in the PMS (e.g., mSettings, mInstaller, systemConfig, etc.).

In the scanning system partition stage, the PMS scans application packages under a system directory (system directory), the system may be called a system partition, the partition is mainly used for storing Android system related files and frames, the system directory includes a plurality of sub-directories, the PMS scans files under each sub-directory, for example, files under a directory of the system APP, the system/framework, and the like, and performs some subsequent processing on the scanned files.

In the scan data partition stage, the PMS scans an application package under a data directory (data directory)/data may be referred to as a data partition, which is mainly used to store personal data and configuration files of all users, the data directory includes a plurality of subdirectories, and the PMS scans files under each subdirectory, for example, files under a directory of/data/APP (subdirectories storing the data of a third party APP),/data/system (subdirectories storing the data of a system configuration file),/data/data (subdirectories storing the data of all installed APPs), and updates application information under the data directory in time to remove unnecessary data.

UID information of the application related to the embodiment of the application is stored in the data directory.

In the scanning ending stage, the PMS can judge whether the version of the current platform software development kit (SoftwareDevelopmentKit, SDK) is different from the version of the SDK at the last starting time, and if so, the permission is updated; whether the OTA is started for the first time after upgrading can also be judged, if yes, unnecessary buffer data are cleared; files such as package xml may also be updated.

In the preparation phase, the PMS creates a PackageInstaliteService object, and performs memory garbage collection and the like.

The PMS installs and uninstalls the application package on the terminal equipment and the like are mainly completed through an instron and an instron, wherein the instron is an API interface provided by a Java layer, and the instron is DaemonService started by an init process.

In general, a system application on a terminal device is granted high authority, for example, the system application can be set to run in a system process by setting Android: shareduser = "Android. User. System", the system application has system authority (for example, root authority), system configuration can be modified, and meanwhile, a plurality of applications can be configured to run in one process for data sharing. In this way, the high authority of the system applications easily brings huge potential safety hazards to the system, and once the system applications are broken, the system configuration is controlled, and the user data and the system data are revealed and other safety risks are caused. Therefore, in order to reduce the security risk, the UID of these System applications needs to be changed and modified, for example, the device id of the System application may be changed by removing the attribute of the System application Android = "shared. Ui. System", so that the UID of the System application may be further changed, where the System application may be an application preset by an Operating System (OS) of the terminal device, for example, an application such as setting, information, dialing, and the like.

The UID change of an application may cause that the data resource of the old UID (i.e. the UID before the change) application is not available for the new UID (i.e. the UID after the change), that is, after the UID change of the application, the user cannot access the original directory file of the application before the UID change, resulting in data loss.

Aiming at the problems, the current solution is to repair the genus group and the authority of the data catalogue of the application, so that the new UID application also has the authority to access the data catalogue of the old UID application, thereby ensuring that after the UID of the application is changed, the data of the old UID application is still available for the new UID application, namely, the user can normally access the data catalogue of the old UID application.

The specific implementation process of the solution is as follows:

first, during the process of the PMS scanning the application package, the PMS invokes the instrument process for preparing user data for each application on the terminal device.

Further, scanning UID/GID to which a currently applied data directory belongs by calling an instrument process, wherein the data directory comprises a data directory under a credential Encrypted (CredentialEncrypted, CE) storage space and a data directory under a Device Encrypted (DE) storage space, wherein the CE storage space is a default storage position which can be used for application and can be used only after a user unlocks a terminal Device; the DE memory space is available for use by the terminal device in a direct start mode and after the user unlocks the terminal device.

Further, after scanning, if the UID/GID to which the data directory belongs is determined to be changed, repairing is carried out, and the original UID/GID is changed into the changed UID/GID.

However, for some applications that use the android keystore system (android keystore system) to encrypt and decrypt data, the key files used by the android keystore system are uniformly managed by a keystore service module (keystore service), and the file names of the key files are generated by the keystore service based on the UID, the key type and the key alias of the application. After the application is changed by UID, not only the UID of the data directory of the application is changed, but also the expected file name of the key file in the android key library used by the application (i.e. the file name generated based on the changed UID) is changed, in the above solution, the problem of the expected file name change of the key file in the android key library caused by the UID change of the application is not considered, so after the UID change of the application, when the new UID application calls the android key library to decrypt data, the keystore will encode and generate the file name (i.e. the expected file name) of the new key file based on the new UID, but because the file name of the key file stored in the android key library is not automatically renamed along with the UID change of the application, the keystore 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 successfully decrypt the encrypted data of the old UID, i.e. the decryption failure, and the loss of the application data may be caused, and the loss of the new UID application, the account number, the login failure information, the user protocol, the user experience and the like are reduced, and the user experience is bad.

For example, as shown in fig. 1A, before the UID of the application is changed, the user interface 100 displays account information (for example, account name Mary, etc.) of the user and history data information (for example, history data recorded in my collection, latest play, download, etc.) generated during the use of the application, that is, the terminal device 100 stores the account information of the user and the history 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 account information of the user stored on the terminal device 100 before the UID of the application is changed is not displayed on the user interface 110, and the history data information generated during the use of the application by the user before the UID of the application is changed is also cleared (for example, the number of data items stored in the my collection list is changed from 30 in fig. 1A to 0 in fig. 1B), that is, the terminal device 100 fails to decrypt the encrypted data of the old UID application, thereby causing the encrypted data to be lost.

Aiming at the problem that the decryption of the encrypted data fails due to the fact that the UID of the application is changed but the file name of the key file stored on the key storage service side is not changed, the embodiment of the application provides a key migration method, after the terminal equipment determines that the application changes the UID, the key file stored on the key storage service side before the application changes the UID can be repaired, namely, the key migration can be realized by migrating the data in one stored key file into another new key file, so that the application can find the correct key file (namely the new key file) when the application searches the key file by using the file name of the key file generated on the basis of the changed UID after the application changes the UID, the encrypted data can be successfully decrypted by using the correct key file, the decryption failure and the encrypted data loss are avoided, the service continuity is improved, and the user experience is improved.

In the embodiment of the application, the terminal device may change the UID of the application through Over The Air (OTA), where the change of the UID of the application refers to that the UID of the application is different before and after the OTA under the same user.

The key migration method provided by the embodiment of the application can be triggered to be executed under the following two scenes:

1. the method is triggered to be executed in the scene of the PMS scanning application program package, wherein the condition for triggering the PMS scanning application program package is as follows: the terminal device 100 is powered on and restarted after the completion of the OTA, or the terminal device 100 performs multi-user handover (e.g., handover from the default user to user 1) in response to the operation of the handover user after the completion of the OTA. Under the circumstance, the key migration method provided by the embodiment of the application can uniformly repair file names of a plurality of key files stored on the KeyStoreService side.

2. The application is triggered to execute in a scenario where a key needs to be acquired (i.e., a key file needs to be queried) during the start-up 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 stored on the keystore side for the current single application.

The specific procedure of triggering execution of the key migration method in these two scenarios will be described in detail in the following embodiments, and will not be expanded here.

In the embodiment of the present application, the terminal device 100 is taken as an example of a mobile phone, and the terminal device 100 may also be an intelligent terminal device such as a tablet personal computer (Pad), a smart screen, a personal digital assistant (Personal Digital Assistant, PDA), a Laptop (Laptop), etc., which is not limited to the type, physical form and size of the terminal device 100.

The key migration method provided in the embodiment of the present application may be applicable to a UID change scenario of a system application on a terminal device 100 that uses an android keystore system to encrypt and decrypt data, and is not limited thereto, and the key migration method provided in the embodiment of the present application may also be applicable to a UID change scenario of another application on a terminal device 100 that uses an android keystore system to encrypt and decrypt data, which is not limited thereto.

The key migration method triggered and executed in the scene of the PMS scanning application program package is described in the following.

Fig. 2 illustrates a flow of triggering execution of a key migration method in a scenario of a PMS scanning application package according to an embodiment of the present application. As shown in fig. 2, the method may be applied to the terminal device 100, wherein the terminal device 100 may include: application package management service module (PMS), instreller, service management module (ServiceManager), instrald, android keystore, keystore service module (keystore service).

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

the terminal device 100 can acquire the new UID and the old UID of the application, and under the condition that the new UID and the old UID are different, the terminal device 100 can perform key migration again, so that the application can still find a correct key file to decrypt the encrypted data when decrypting the data after changing the UID, and decryption failure and encrypted data loss are avoided.

Illustratively, one possible implementation of the terminal device 100 to obtain the new UID and the old UID of the application may be an implementation described in the following stage one (step S201-step S207), and the specific implementation of the stage one is described in detail below:

stage one (step S201-step S207): stage of obtaining new and old UIDs

S201-S202, after detecting that OTA is completed and then starting up and restarting or switching multiple users, an application package management service module of the terminal device 100 sends a request for inquiring about new and old UIDs to an instrler.

Triggering the terminal device 100 for OTA upgrades may include, but is not limited to, the following two implementations:

implementation 1: the terminal device 100 automatically prompts the user to perform OTA upgrade, and after the user agrees, the terminal device 100 is triggered to perform OTA upgrade.

Illustratively, referring to fig. 3A, the terminal device 100 may display a pop-up window 300 for prompting the user to update the system version, a prompting message (e.g., "find new version of system") and an "update immediately" option 301 may be included in the pop-up window 300, and the terminal device 100 may detect an operation (e.g., a click operation) of the user on the "update immediately" option 301, and in response to this operation, the terminal device 100 may perform a system update, that is, perform an OTA upgrade.

Implementation 2: the user actively enters the "setup" application to trigger the terminal device 100 to perform OTA upgrades.

Referring to fig. 3B, an example of a user interface 310 of a "setup" application of the terminal device 100 is shown in fig. 3B, where the user interface may display a plurality of setup options (e.g., a "user and account" option 311, a "system and update" option 312, etc.), the terminal device 100 may detect an operation (e.g., a click operation) of the user with respect to the "system and update" option 312, in response to which the terminal device 100 may display the user interface 320 as shown in fig. 3C, further, the terminal device 100 may detect an operation (e.g., a click operation) of the user with respect to the "software update" option 321, in response to which the terminal device 100 may display the user interface 330 as shown in fig. 3D, where the user interface displays prompt information (e.g., a "new version found") and an "update immediately" option 331, in response to which the terminal device 100 may detect an operation (e.g., a click operation) of the user with respect to the "update immediately" option 331, that is updated by the terminal device 100 may perform a system, i.e., an OTA.

After the terminal device 100 completes the OTA upgrade, the power-on restart may be automatically performed, and a user interface 340, as exemplarily shown in fig. 3E, may be displayed, where the user interface may display a prompt message "in power-on" to prompt that the user terminal device 100 is being restarted.

Referring to fig. 3F-3H, fig. 3F-3H illustrate the process of multi-user handoff after the OTA is complete.

The terminal device 100 may detect an operation (e.g., a click operation) of the user with respect to the "user and account" option 311 in fig. 3B, in response to which the terminal device 100 may display a user interface 350 as exemplarily shown in fig. 3F, it may be seen that the user currently logged in to the terminal device 100 is an owner user (may also be referred to as a default user), the terminal device 100 may detect an operation (e.g., a click operation) of the user with respect to the option 351, in response to which the terminal device 100 may display a user interface 360 as exemplarily shown in fig. 3G, which displays a plurality of options (e.g., an option 361, an option 362, etc.), it may be seen that there are two users that may log in to the terminal device 100: the user currently logged in to the terminal device 100 is the owner user, and if the user wants to switch to the user 1 to log in to the terminal device 100, the terminal device 100 may detect an operation (e.g., a click operation) of the user with respect to the option 362, in response to which the terminal device 100 may display a pop-up window 370 as shown in fig. 3H, and further, the terminal device 100 may detect an operation (e.g., a click operation) of the user with respect to the option 371, in response to which the terminal device 100 may switch the user currently logged in to the terminal device 100 from the owner user to the user 1, thereby completing the multi-user switching.

After the terminal device 100 performs a startup restart process after the OTA is completed (see fig. 3E) or detects an operation of multi-user switching after the OTA is completed (for example, the user performs an operation on the option 371 in fig. 3H), the application package management service module of the terminal device 100 may be triggered to perform a process of scanning application packages, scan all application packages under the user currently logged in the system, and repair the data directory thereof.

In this embodiment of the present application, after detecting that the OTA is started up and restarted or after the OTA is completed and after switching between multiple users, the application package management service module of the terminal device 100 starts to execute the process of scanning the application package, taking the scanning system application 1 as an example, the application package management service module may also send a request for querying the new and old UID to the instructor, where the request may carry information such as a package name of the system application 1, where the request is used to instruct the instructor to query the new UID and the old UID of the system application 1, the new UID refers to the UID of the system application 1 after the current OTA upgrade is started up and restarted/after the OTA is switched between multiple users, and the old UID refers to the UID of the system application 1 before the current OTA upgrade is started up and before the current OTA upgrade is switched between multiple users.

After receiving the request for querying the new and old UIDs, the instrer of the terminal device 100 may send a request for querying the new and old UIDs to the instral, and one possible implementation is the implementation described in the following steps S203-S204:

S203-S204, the Installer of the terminal device 100 sends a request for acquiring service 1 to a service management module, wherein the service 1 is used for inquiring the new UID and the old UID, and the service management module sends a request for inquiring the new UID and the old UID to the Installer after receiving the request for acquiring the service 1 sent by the Installer.

Specifically, after receiving the request for querying the new UID sent by the application packet management service module, the instrler of the terminal device 100 may send a request for acquiring the service 1 to the service management module, where the service 1 is a service for querying the new UID. After receiving the request sent by the instrer to obtain the service 1, the service management module may send a request for querying the new UID and the old UID to the instron, where the request may carry information such as a packet name of the system application 1, and the request is used to instruct the instron to query the new UID and the old UID of the system application 1.

The service management module transmits the request for inquiring the new UID and the old UID to the Inlitald through a binder; the binder is a mechanism of Inter-process communication (Inter-Process Communication, IPC) and can realize data interaction among a plurality of processes; transparent transmission (i.e., transparent transmission) refers to communication in which only the transmitted content is responsible for being sent from a source address to a destination address without any change to the transmitted content.

After receiving the request for querying the new UID and the old UID, the instrument of the terminal device 100 may send the new UID and the old UID to the application packet management service module, and one possible implementation manner is the implementation manner described in the following steps S205 to S207:

S205-S207, the Inlitald of the terminal device 100 sends a new UID and an old UID to the service management module, the service management module sends the new UID and the old UID to the Inlitaler after receiving the new UID and the old UID sent by the Inlitaler, and the Inlitaler sends the new UID and the old UID to the application package management service module after receiving the new UID and the old UID sent by the service management module.

Specifically, after receiving the request for querying the new and old UIDs sent by the service management module, the instral of the terminal device 100 may query the new and old UIDs of the system application 1, after querying the new and old UIDs of the system application 1, the instral may send the new and old UIDs of the system application 1 to the service management module, after receiving the new and old UIDs of the system application 1 sent by the instral, the service management module may send the new and old UIDs of the system application 1 to the instral, and after receiving the new and old UIDs of the system application 1 sent by the service management module, the instral may send the new and old UIDs of the system application 1 to the application package management service module.

It can be seen that, by performing the step S201-step S209 of the first stage, the PMS can obtain the new UID and the old UID of all applications installed on the terminal device 100, so that the steps in the subsequent second stage can be performed for the terminal device 100, i.e. the following second stage can be continuously performed after the first stage is performed. In some embodiments, after the first stage is performed, other tasks may be performed based on the obtained new UID and the old UID, instead of performing the second stage, for example, after the first stage is performed, based on the obtained new UID and the old UID of all applications, the terminal device 100 may determine which applications are sharing the same UID, further may obtain other relevant information (such as granted rights information) of the applications, so that the applications may be further managed (such as rights management), and so on; the terminal device 100 may further determine whether the UID change of the application is successful by determining whether the new UID and the old UID of the same application are different, and so on.

Stage two (step S208-step S217): key migration phase

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

Specifically, after receiving the new UID and the old UID of the system application 1 sent by the instrler, the application packet management service module of the terminal device 100 may compare the new UID and the old UID of the system application 1 to determine whether the new UID and the old UID are the same, if so, the application packet management service module determines that the UID of the system application 1 is not changed, and the application packet management service module does not execute the subsequent steps any more; if the two types of applications are different, the application package management service module determines that the UID of the system application 1 is changed, and optionally, the application package management service module also determines whether the currently processed application belongs to the system application, for example, the application package management service module determines whether the system application 1 belongs to the system application, and if so, the application package management service module continues to execute subsequent steps.

It should be noted that, the manner in which the application package management service of the terminal device 100 obtains the new UID and the old UID of the application may include, but is not limited to, the manner in which the new UID and the old UID are obtained as described in the above stage one.

After determining the UID change, the application package management service module of the terminal device 100 may send an instruction to migrate the key to the key store service module, and one possible implementation is an implementation described in the following steps S209-S211:

S209-S211, an application package management service module of the terminal equipment 100 sends a migration key instruction to an android key bank, wherein the instruction comprises information such as package names, new UIDs, old UIDs and the like of applications, the android key bank sends a request for acquiring a service 2 to a service management module after receiving the instruction, the service 2 is a migration key service, and the service management module sends the migration key instruction to a key bank service module after receiving the request.

Specifically, after determining that the UID of the system application 1 is changed, the application package management service module of the terminal device 100 may send an instruction for migrating the key to the android keystore, where the instruction may include information such as a package name, a new UID, and an old UID of the system application 1. After receiving the instruction of the migration key sent by the application package management service module, the android key library can send a request for obtaining the service 2 to the service management module, wherein the service 2 is the migration key service. After receiving the request for obtaining the service 2 sent by the android keystore, the service management module may send an instruction for migrating the key to the keystore service module, where the instruction may include information such as a packet name, a new UID, an old UID, etc. of the system application 1, and the instruction is used to instruct the keystore service module to execute the key migration operation.

The service management module transmits the key migration command to the key store service module through the binder in the same manner as the data transmission in step S204.

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

Specifically, after receiving the instruction of migrating the key sent by the service management module, the key library service module of the terminal device 100 may first find all key files corresponding to the package name based on the package name of the system application 1, further, in order to improve security, call authority checking, configuration list checking, key integrity checking, and file attribute checking may be performed again, and after confirming that all the four checks pass, the key library service module performs the subsequent steps.

The key store service module performs the following specific execution process of the four checks:

invoking permission checking: the key library service module confirms whether the IPC opposite end process calling the key library service process is a system process, and if the IPC opposite end process is the system process, the key library service module confirms that the calling authority check passes.

Configuration list checking: the key library service module determines whether the package name of the system application 1 allows key migration or not based on the configuration information corresponding to the package name of the system application 1 recorded in the configuration list, if so, the key library service module confirms that the configuration list passes the checking, and the key library service module further determines which keys corresponding to the package name of the system application 1 need to be migrated.

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

File attribute inspection: the key library service module is used for checking the genus group and the authority of all key files corresponding to the package names of the system application 1 by calling the instruments and is used for eliminating the potential hidden trouble that the keys are illegally operated.

The time sequence of the key store service module to execute the four checks is not limited in the embodiment of the present application.

In some embodiments, step S212 is optional.

In some embodiments, after one or more of the four checks pass, the keystore service module may perform subsequent steps.

In one possible implementation, after the keystore service module finds all key files corresponding to the package name based on the package name of the system application 1, since the file names of all current key files are generated by encoding based on the old UID, the key type, and the key alias of the system application 1, the keystore service module may determine which of the two UIDs (new UID and old UID) sent from the service management module is the old UID and which is the new UID according to the old UID of the application contained in the file names of the key files.

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

Specifically, after confirming that the call authority check, the configuration list check, the key integrity check, and the file attribute check pass, the key library service module of the terminal device 100 may begin to perform a key migration operation, that is, migrate all key files corresponding to the package name of the system application 1.

The key store service module performs key migration operations, including but not limited to the following two possible implementations, where the key store service module migrates one of the above all key files to describe the two possible implementations:

Assuming that the old UID is 1000 and the new UID is 5514, the key file required for decrypting the data 1 is the key file 1, if the file name of the key file 1 corresponding to the old UID (i.e. the current file name of the key file 1) is 1000_usrpkey_xx according to the naming rule of the key file by the android keystore system, the file name of the key file 1 corresponding to the new UID is 5514_usrpkey_xx, that is, after the UID of the application is changed, only the UID field is changed in the file name of the same key file, and other fields (such as the key type and the key alias) are unchanged.

Possible implementation 1:

the keystore service module may migrate the data stored in the key file with the file name 1000_usrpkey_xx (i.e. the above-mentioned key file 1) to another new key file with the file name 5514_usrpkey_xx, so that the data stored in the key file with the file name 1000_usrpkey_xx is stored in the new key file, where the data stored in the key file may include key information required for decrypting the encrypted data.

Alternatively, after the data migration is finished, the keystore service module may delete the key file with the file name 1000_usrpkey_xx.

Possible implementation 2:

the keystore service module may only modify the file name of the key file 1 corresponding to the old UID from 1000_usrpkey_xx to the file name 5514_usrpkey_xx of the key file 1 corresponding to the new UID, in this case, the new key file is still the key file 1, but the file name is changed from 1000_usrpkey_xx to 5514_usrpkey_xx, and the data stored in the file is not changed.

In this way, by executing 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 key of the encrypted data required by the decryption process can be obtained based on the key file, so that the loss of the encrypted data can be avoided, and the user experience can be improved.

S214, the key library service module of the terminal equipment 100 confirms that the key integrity check and the file attribute check of the new key file pass.

Specifically, after the key store service module of the terminal device 100 performs the key migration operation, the key integrity check and the file attribute check may be performed on the new key file, and if the key integrity check and the file attribute check of the new key file are confirmed to pass, the key store service module confirms that the key migration is successful.

The specific execution process of the key store service module for performing the key integrity check and the file attribute check may refer to the foregoing related content, which is not described herein again.

In some embodiments, step S214 is optional.

In some embodiments, the keystore service module may confirm that the key migration was successful after confirming that one of the key integrity check and the file attribute check of the new key file passed.

After the key store service module of the terminal device 100 completes the key migration, a key migration success instruction may be sent to the application package management service module, and one possible implementation manner is the implementation manner described in the following steps S215 to S217:

S215-S217, a key library service module of the terminal equipment 100 sends a key migration success instruction to a service management module, the service management module sends the key migration success instruction to an android key library after receiving the key migration success instruction, and the android key library sends the key migration success instruction to an application package management service module after receiving the key migration success instruction.

The key migration success instruction is used for notifying the application program package management service module that the key library service module has successfully completed key migration.

In some embodiments, steps S215-S217 are optional.

After the application UID is changed, the terminal device 100 may still display the same user interface as the user interface 100 shown in fig. 1A, that is, the terminal device 100 still stores account information (such as account name Mary) of the user and historical data information generated during the use of the application by the user, that is, by implementing the key migration method provided in the embodiment shown in fig. 2, after the application UID is determined to be changed, the terminal device 100 repairs the key file stored by the application on the keystore side, so as to implement key migration, thereby ensuring that the application can still find the correct key file to decrypt encrypted data when decrypting the data after changing the UID, avoiding decryption failure and encrypted data loss, improving service continuity, and improving user experience.

Another key migration method triggered and executed in the scenario of the PMS scanning application package provided in the embodiment of the present application is described below.

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

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

Specifically, after the terminal device 100 performs the startup restart process after the OTA is completed (see fig. 3E) or detects the operation of multi-user switching after the OTA is completed (for example, the user performs the operation on option 371 in fig. 3H), the PMS may be triggered to scan the application package, and taking the scan system application 1 as an example, the terminal device 100 may query the new UID and the old UID of the system application 1 through the instractions, so as to obtain the new UID and the old UID of the system application 1, where the new UID refers to the UID of the system application 1 after the current OTA upgrade startup restart/after the current OTA upgrade multi-user switching, and the old UID refers to the UID of the system application 1 before the current OTA upgrade startup restart/before the current OTA upgrade multi-user switching.

S403, the terminal device 100 determines whether the new UID and the old UID of the application are different.

Specifically, after the terminal device 100 obtains the new UID and the old UID of the system application 1, the new UID and the old UID of the system application 1 may be compared to determine whether the new UID and the old UID are different, if not, the terminal device 100 determines that the UID of the system application 1 is not changed, and the terminal device 100 does not execute the subsequent steps any more; if so, the terminal device 100 determines that the UID of the system application 1 has been changed. Optionally, the terminal device 100 also determines whether the currently processed application belongs to a system application, for example, the terminal device 100 determines whether the system application 1 belongs to a system application, if so, the terminal device 100 continues to execute the subsequent steps.

S404, the terminal equipment 100 judges whether the call authority check, the configuration list check, the key integrity check and the file attribute check pass.

Specifically, if all the four checks pass, the terminal device 100 continues to execute the subsequent steps, and performs key migration, and if all the four checks do not pass, the terminal device 100 does not execute the subsequent steps any more.

The specific execution process of the terminal device 100 for performing the above four checks may refer to the relevant content in step S212 in the embodiment shown in fig. 2, which is not described herein.

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

The specific implementation process of step S405 may refer to the relevant content in step S213 in the embodiment shown in fig. 2, which is not described herein.

S406 to S409, is the terminal device 100 judging whether the key integrity check of the new key file and the file attribute check 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 is failed.

Specifically, after migrating the key file and obtaining the new key file, the terminal device 100 may perform a key integrity check and a file attribute check on the new key file, if both checks pass, the terminal device 100 may confirm that the key migration is successful, and if both checks do not pass, the terminal device 100 may delete the new key file and confirm that the key migration fails.

The specific execution process of the key integrity check and the file attribute check by the terminal device 100 may refer to the related content in the embodiment shown in fig. 2, which is not described herein.

The key migration method for triggering execution of the application in a scenario where the application needs to acquire a key in the starting and running process is described below.

Fig. 5 illustrates a flow of triggering execution of a key migration method in a scenario where an application needs to acquire a key in a startup and running process according to an embodiment of the present application. As shown in fig. 5, the method may be applied to the terminal device 100, wherein the terminal device 100 may include: application 1 (APP 1), android keystore (android keystore), keystore service module (keystore), service management module (ServiceManager), instreld.

Illustratively, one possible implementation of the terminal device 100 to obtain the new UID and the old UID of the application may be an implementation described in the following stage one (step S501-step S509), and the specific implementation of the stage one is described in detail below:

stage one (step S501-step S509): stage of obtaining new and old UIDs

First, the application 1 of the terminal device 100 may send a request for obtaining a key to the keystore service module, one possible implementation is the implementation described in the following steps S501-S503:

S501-S503, after detecting that the application 1 is started and running, the terminal device 100 sends a request for obtaining the key 1 to the android keystore, where the request carries information such as a new UID, a key alias of the key 1, a key type, and the like, and after receiving the request for obtaining the key 1, the android keystore sends the request for obtaining the key to the keystore service module.

Specifically, taking an example that the application 1 is a system application, after detecting that the application 1 is started and runs, the terminal device 100 may detect that the application 1 needs to acquire the key 1, and then the application 1 may send a request for acquiring the key 1 to the android keystore, where the request carries information of a new UID, a key alias of the key 1, a key type, and the like, where the key 1 is a key required for decrypting encrypted data in the application 1, and the new UID is a current UID of the application 1. The android keystore may send a request for acquiring the key 1 to the keystore service module after receiving the request for acquiring the key 1 sent by the application 1.

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

Specifically, after receiving a request for acquiring a key 1 sent by the android keystore, the keystore service module of the terminal device 100 may query, in a configuration list, a package name of an application corresponding to the key alias of the key 1 based on the key alias of the key 1 carried in the request, where a mapping relationship between the key alias and the package name of the application is stored in the configuration list. Further, the keystore service module may determine, according to the mapping relationship, that a package name of an application corresponding to the key alias of the key 1 exists in the configuration list, and further, the keystore service module may determine that the package name of the application corresponding to the key alias of the key 1 is the package name of the application 1.

In some embodiments, the request for obtaining the key 1 may further carry the packet name of the application 1, where step S504 may not be performed.

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

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

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

Further, the keystore service module of the terminal device 100 may send a request to query the old UID to the instrument, one 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 inquiring the old UID to the service management module, wherein the request carries information such as the packet name of the application corresponding to the key alias of the key 1, and the service management module sends the request for inquiring the old UID to the instrument after receiving the request for inquiring the old UID.

Specifically, after determining that the package name of the application corresponding to the key alias of the key 1 exists and determining that the key file corresponding to the file name 1 does not exist, the keystore service module of the terminal device 100 may send a request for querying the old UID to the service management module, where the request carries information such as the package name of the application corresponding to the key alias of the key 1 (i.e., the package name of the application 1), where the old UID is the initial UID of the application 1 (i.e., the UID before changing to the new UID). The service management module, upon receiving a request to query the old UID, may send a request to query the old UID to the instron, the request indicating the old UID of instron query application 1.

The service management module transmits the request for inquiring the old UID to the Inlitald through the binder.

Further, the instrument of the terminal device 100 may send the old UID to the keystore service system after receiving the request to query the old UID, one possible implementation is the implementation described in the following steps S508-S509:

S508-S509, the Insald 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 the Insald.

Specifically, after receiving the request for querying the old UID sent by the service management module, the instrument of the terminal device 100 may query the old UID of the application 1, after querying the old UID of the application 1, the instrument may send the old UID of the application 1 to the service management module, and after receiving the old UID of the application 1 sent by the instrument, the service management module may send the old UID of the application 1 to the keystore service module.

Stage two (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 the application 1 sent by the service management module, the key library service module of the terminal device 100 may compare the old UID of the application 1 with the new UID of the application 1, and determine whether the old UID is identical to the new UID, if so, the key library service module determines that the UID of the application 1 is not changed, and the key library service module does not execute the subsequent steps any more; if the two types of applications are different, the keystore service module determines that the UID of the application 1 is changed, and optionally, the keystore service module also determines whether the current application belongs to a system application, for example, the keystore service module determines whether the application 1 belongs to the system application, and if so, the keystore service module continues to execute the subsequent steps.

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

Specifically, the keystore service module of the terminal device 100 may encode and generate the filename 2 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, further, the keystore service module may search the key file corresponding to the filename 2, and if it is confirmed that the key file corresponding to the filename 2 exists, the keystore service module may continue to execute the subsequent steps.

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

Specifically, after determining that the UID of the application 1 is changed and determining that the key file corresponding to the file name 2 exists, the key repository service module of the terminal device 100 may first invoke permission checking, configuration list checking, key integrity checking, and file attribute checking, and after confirming that all the four checks pass, the key repository service module may execute the subsequent steps.

The key store service module performs the following specific processes of the four checks:

Configuration list checking: the key library service module determines whether the package name of the application 1 allows key migration or not based on the configuration information corresponding to the package name of the application 1 recorded in the configuration list, and if so, the key library service module confirms that the configuration list passes the check.

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

File attribute inspection: and the key library service module is used for checking the genus group and the authority of the key file corresponding to the file name 2 by calling the instrument and eliminating the potential hidden trouble of illegal operation of the key.

In some embodiments, step S512 is optional.

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

Specifically, after confirming that the call authority check, the configuration list check, the key integrity check, and the file attribute check pass, the key library service module of the terminal device 100 may begin to perform a key migration operation, that is, migrate the key file corresponding to the file name 2, to obtain a new key file.

Wherein the keystore service module performs the key migration operation may include, but is not limited to, the following two possible implementations:

possible implementation 1:

the key store service module may migrate the data stored in the key file corresponding to the file name 2 to another new key file, where the file name of the new key file is the file name 1 generated based on the new UID, the key alias of the key 1, and the key type of the key 1, so that the data stored in the key file corresponding to the file name 2 is stored in the new key file.

Optionally, after the data migration is finished, the keystore service module may delete the key file corresponding to the file name 2.

Possible implementation 2:

the keystore service module may modify only the file name of the key file corresponding to the file name 2 from the file name 2 to the file name 1, in which case the new key file is still the key file corresponding to the file name 2, but the file name is changed from the file name 2 to the file name 1, and the data stored in the file is not changed.

S514, the key store service module of the terminal equipment 100 confirms that the key integrity check and the file attribute check of the new key file pass.

In some embodiments, step S514 is optional.

Further, the keystore service module of the terminal device 100 may send a new key file to the application 1 after confirming that the key migration is successful, one possible implementation is the implementation described in the following steps S515-S517:

S515-S517, the keystore service module of the terminal device 100 sends a new key file to the android keystore, after the android keystore receives the new key file, the new key file is sent to the application 1, and after the application 1 receives the new key file, the 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 may send a new key file to the android key store, where the new key file is a key file corresponding to the file name 1 after the key migration, and after the android key store receives the new key file, the new key file may be sent to the application 1, and after the application 1 receives the new key file, the application 1 may obtain the key 1 based on the data stored in the new key file, so that the encrypted data may be decrypted by using the key 1. Therefore, the phenomena of encrypted data loss and decryption failure are avoided, and the user experience is improved.

Another key migration method that is triggered and executed by the application and is provided in the embodiment of the present application in a scenario where a key needs to be acquired during a startup and operation process is described below.

Fig. 6 illustrates a flow of triggering execution of a key migration method in a scenario where another application provided in an embodiment of the present application needs to acquire a key during a startup and operation process. As shown in fig. 6, the method may be applied to the terminal device 100, and the specific steps of the method will be described below taking UID change applied by the system on the terminal device 100 as an example:

s601, the terminal device 100 determines that the key 1 needs to be acquired.

Specifically, taking the example that the application 1 is a system application, the terminal device 100 may determine that the key 1 needs to be acquired after detecting that the application 1 is started and run, where the key 1 is a key required to decrypt encrypted data in the application 1.

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

The specific implementation process of step S602 may refer to the related content in step S504 in the embodiment shown in fig. 5, which is not described herein.

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

The new UID of the application 1 may be acquired by the terminal device 100 through the application 1, and the old UID of the application 1 may be acquired by the terminal device 100 through the instrument.

S604, the terminal device 100 determines whether the new UID and the old UID of the application 1 are different, and whether a key file required for acquiring the key 1 exists.

Specifically, the terminal device 100 may determine whether the new UID and the old UID of the application 1 are different, and if so, the terminal device 100 determines that the UID of the application 1 has been changed. Further, the terminal device 100 may further determine whether a key file required for acquiring the key 1 exists, specifically: the terminal device 100 may 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 for obtaining the key 1 cannot be queried, further, the terminal device 100 may generate the file name 2 based on the old UID, the key alias of the key 1, and the key type, and query the key file required for obtaining the key 1 according to the file name 2, and if the key file required for obtaining the key 1 can be queried, the terminal device 100 determines that the key file exists.

After determining that the new UID and the old UID of the application 1 are different and that the key file required for acquiring the key 1 is present, the terminal device 100 may continue to perform the subsequent steps, otherwise, the subsequent steps are not performed any more.

S605, the terminal equipment 100 judges whether the call authority check, the configuration list check, the key integrity check and the file attribute check pass.

The specific implementation process of step S605 may refer to the related content in step S512 in the embodiment shown in fig. 5, which is not described herein.

S606, the terminal equipment 100 migrates the key file to obtain a new key file.

The specific implementation process of step S606 may refer to the relevant content in step S513 in the embodiment shown in fig. 5, which is not described herein.

S607-S610, is the terminal device 100 determining that the key integrity check of the new key file and the file attribute check pass? If yes, 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 migrating the key file to obtain the new key file, the terminal device 100 may perform a key integrity check and a file attribute check on the new key file, if both checks pass, the terminal device 100 may confirm that the key migration is successful, and the terminal device 100 may acquire the key 1 based on the new key file, so as to decrypt encrypted data by using the key 1, and if both checks do not pass, the terminal device 100 may delete the new key file and confirm that the key migration fails, and the terminal device 100 cannot decrypt the encrypted data by using the key 1.

The specific execution process of the key integrity check and the file attribute check by the terminal device 100 may refer to the related content in the embodiment shown in fig. 5, which is not described herein.

As can be seen from the embodiments shown in fig. 4 to fig. 6, by implementing the key migration method provided in the present application, in the case of changing the UID of the application, the terminal device 100 may perform a PMS scanning application package stage triggered by startup and multi-user switching after the OTA is completed, or, in the application startup and operation process, need to obtain a key stage to repair a key file stored on the keystore side, so as to implement key migration, thereby ensuring that the application can still find a correct key file to decrypt encrypted data after changing the UID, avoiding decryption failure and loss of encrypted data, improving the fault tolerance of key migration, improving user experience, and, before and after key migration, the terminal device 100 performs a key integrity check and a file attribute check on the key file, and ensuring that the whole key migration process is trusted.

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

The following describes a structure of a terminal device 100 provided in an embodiment of the present application.

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

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

It is to be understood that the structure illustrated 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, terminal device 100 may include more or less components than illustrated, or certain components may be combined, or certain components may be split, or different arrangements of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

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

The controller may be a neural center and a command center of the terminal device 100. The controller can generate operation control signals according to the instruction operation codes and the time sequence signals to finish the control of instruction fetching and instruction execution.

A memory may also be provided in the processor 110 for storing instructions and data. In some embodiments, the memory in the 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 reuse the instruction or data, it may be called directly from memory. Repeated accesses are avoided and the latency of the processor 110 is reduced, thereby improving the efficiency of the system.

In some embodiments, the processor 110 may include one or more interfaces. The interfaces 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 receiver transmitter (universal asynchronous receiver/transmitter, UART) interface, a mobile industry processor interface (mobile industry processor interface, MIPI), a general-purpose input/output (GPIO) interface, a subscriber identity module (subscriber identity module, SIM) interface, and/or a universal serial bus (universal serial bus, USB) interface, among others.

The I2C interface is a bi-directional synchronous serial bus comprising a serial data line (SDA) and a serial clock line (derail clock line, SCL). In some embodiments, the processor 110 may contain multiple sets of I2C buses. The processor 110 may be coupled to the touch sensor 180K, charger, flash, camera 193, etc., respectively, 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 and the touch sensor 180K communicate through an I2C bus interface to implement a touch function of the terminal device 100.

The I2S interface may be used for audio communication. In some embodiments, the processor 110 may contain multiple sets of I2S buses. The processor 110 may be coupled to the audio module 170 via an I2S bus to enable communication between the processor 110 and the audio module 170. In some embodiments, the audio module 170 may transmit an audio signal to the wireless communication module 160 through the I2S interface, to implement a function of answering a call through the bluetooth headset.

PCM interfaces may also be used for audio communication to sample, quantize and encode analog signals. 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 may also transmit audio signals to the wireless communication module 160 through the PCM interface to implement a function of answering a call through the bluetooth headset. Both the I2S interface and the PCM interface may be used for audio communication.

The UART interface is a universal serial data bus for asynchronous communications. The bus may be a bi-directional communication bus. It converts the data to be transmitted between serial communication and parallel communication. In some embodiments, a UART interface is typically used to connect the processor 110 with the wireless communication module 160. For example: the processor 110 communicates with a bluetooth module in the wireless communication module 160 through a UART interface to implement a bluetooth function. In some embodiments, the audio module 170 may transmit an audio signal to the wireless communication module 160 through a UART interface, to implement a function of playing music through a bluetooth headset.

The MIPI interface may be used to connect the processor 110 to peripheral devices such as a display 194, a camera 193, and the like. The MIPI interfaces include camera serial interfaces (camera serial interface, CSI), display serial interfaces (display serial interface, DSI), and the like. In some embodiments, processor 110 and camera 193 communicate through a CSI interface to implement the photographing function of terminal device 100. The processor 110 and the display 194 communicate via a DSI interface to implement the display function of the terminal device 100.

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

The USB interface 130 is an interface conforming to the USB standard specification, and may specifically be a Mini USB interface, a Micro USB interface, a USB Type C interface, or the like. The USB interface 130 may be used to connect a charger to charge the terminal device 100, or may be used to transfer data between the terminal device 100 and a peripheral device. And can also be used for connecting with a headset, and playing audio through the headset. The interface may also be used to connect other terminal devices, such as AR devices, etc.

It should be understood that the interfacing relationship between the modules illustrated in the embodiment of the present invention is only illustrative, 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 use different interfacing manners, or a combination of multiple interfacing manners in the foregoing embodiments.

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

The power management module 141 is used for connecting the battery 142, and the charge management module 140 and the processor 110. The power management module 141 receives input from the battery 142 and/or the charge management module 140 and provides power to the processor 110, the internal memory 121, the external memory, the display 194, the camera 193, the wireless communication module 160, and the like. The power management module 141 may also be configured to monitor battery capacity, battery cycle number, battery health (leakage, impedance) and other parameters. In other embodiments, the power management module 141 may also be provided in the processor 110. In other embodiments, the power management module 141 and the charge management module 140 may be disposed in the same device.

The wireless communication function of the terminal device 100 can 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.

The antennas 1 and 2 are used for transmitting and receiving electromagnetic wave signals. Each antenna in the terminal device 100 may be used to cover a single or multiple communication bands. Different antennas may also be multiplexed to improve the utilization of the antennas. For example: the antenna 1 may be multiplexed into 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 may provide a solution including 2G/3G/4G/5G wireless communication applied to 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), etc. The mobile communication module 150 may receive electromagnetic waves from the antenna 1, perform processes such as filtering, amplifying, and the like on the received electromagnetic waves, and transmit the processed electromagnetic waves to the modem processor for demodulation. The mobile communication module 150 can amplify the signal modulated by the modem processor, and convert the signal into electromagnetic waves through the antenna 1 to radiate. In some embodiments, at least some of the functional modules of the mobile communication module 150 may be disposed in the processor 110. In some embodiments, at least some of the functional modules of the mobile communication module 150 may be provided in the same device as at least some of the modules of the processor 110.

The modem processor may include a modulator and a demodulator. The modulator is used for modulating the low-frequency baseband signal to be transmitted into a medium-high frequency signal. The demodulator is used for demodulating the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low frequency baseband signal to the baseband processor for processing. The low frequency baseband signal is processed by the baseband processor and then transferred to the application processor. The application processor outputs sound signals through an audio device (not limited to the speaker 170A, the receiver 170B, etc.), or displays images or video through the display screen 194. In some embodiments, the modem processor may be a stand-alone device. In other embodiments, the modem processor may be provided in the same device as the mobile communication module 150 or other functional module, independent of the processor 110.

The wireless communication module 160 may provide solutions for wireless communication including wireless local area network (wireless local area networks, WLAN) (e.g., wireless fidelity (wireless fidelity, wi-Fi) network), bluetooth (BT), global navigation satellite system (global navigation satellite system, GNSS), frequency modulation (frequency modulation, FM), near field wireless communication technology (near field communication, NFC), infrared technology (IR), etc., applied to the terminal device 100. The wireless communication module 160 may be one or more devices that integrate at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, modulates the electromagnetic wave signals, filters the electromagnetic wave signals, and transmits the processed signals to the processor 110. The wireless communication module 160 may also receive a signal to be transmitted from the processor 110, frequency modulate it, amplify it, and convert it to electromagnetic waves for radiation via the antenna 2.

In some embodiments, antenna 1 and mobile communication module 150 of terminal device 100 are coupled, and antenna 2 and wireless communication module 160 are coupled, such that terminal device 100 may communicate with a network and other devices via wireless communication techniques. Wireless communication techniques may include global system for mobile communications (global system for mobile communications, GSM), general packet radio service (general packet radio service, GPRS), code division multiple access (code division multiple access, CDMA), wideband code division multiple access (wideband code division multiple access, WCDMA), time division code division multiple access (time-division code division multiple access, TD-SCDMA), long term evolution (long term evolution, LTE), BT, GNSS, WLAN, NFC, FM, and/or IR techniques, among others. The GNSS may include a global satellite positioning system (global positioning system, GPS), a global navigation satellite system (global navigation satellite system, GLONASS), a beidou satellite navigation system (beidou navigation satellite system, BDS), a quasi zenith satellite system (quasi-zenith satellite system, QZSS) and/or a satellite based augmentation system (satellite based augmentation systems, SBAS).

The terminal device 100 implements display functions 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 194 and the application processor. The GPU is 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 194 includes a display panel. The display panel may employ a liquid crystal display (liquid crystal display, LCD). The display panel may also be manufactured using organic light-emitting diode (OLED), active-matrix organic light-emitting diode (AMOLED) or active-matrix organic light-emitting diode (active-matrix organic light emitting diode), flexible light-emitting diode (flex-emitting diode), mini, micro-OLED, quantum dot light-emitting diode (quantum dot light emitting diodes, QLED), or the like. In some embodiments, the terminal device 100 may include 1 or N display screens 194, N being a positive integer greater than 1.

The terminal device 100 may implement a photographing function through an ISP, a camera 193, a video codec, a GPU, a display screen 194, an application processor, and the like.

The ISP is used to process data fed back by the camera 193. For example, when photographing, the shutter is opened, light is transmitted to the camera photosensitive element through the lens, the optical signal is converted into an electrical signal, and the camera photosensitive element transmits the electrical signal to the ISP for processing, so that the electrical signal is converted into an image visible to naked eyes. ISP can also optimize the noise, brightness and skin color of the image. The ISP can also optimize parameters such as exposure, color temperature and the like of a shooting scene. In some embodiments, the ISP may be provided in the camera 193.

The camera 193 is used to capture still images or video. The object generates an optical image through the lens and projects the optical image onto the photosensitive element. The photosensitive element may be a charge coupled device (charge coupled device, CCD) or a Complementary Metal Oxide Semiconductor (CMOS) phototransistor. The photosensitive element converts the optical signal into an electrical signal, which is then transferred to the ISP to be converted into a digital image signal. The ISP outputs the digital image signal to the DSP for processing. The DSP converts the digital image signal into an image signal in a standard RGB, YUV, or the like format. In some embodiments, the terminal device 100 may include 1 or N cameras 193, N being a positive integer greater than 1.

The digital signal processor is used for processing digital signals, and can process other digital signals besides digital image signals. For example, when the terminal device 100 selects a frequency bin, the digital signal processor is used to fourier transform the frequency bin energy, or the like.

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 video in various encoding formats, for example: dynamic picture experts group (moving picture experts group, MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

The NPU is a neural-network (NN) computing processor, and can rapidly process input information by referencing a biological neural network structure, for example, referencing a transmission mode between human brain neurons, and can also continuously perform self-learning. Applications such as intelligent awareness of the terminal device 100 may be implemented by the NPU, for example: image recognition, face recognition, speech recognition, text understanding, etc.

The external memory interface 120 may be used to connect an external memory card, such as a Micro SD card, to realize expansion of the memory capability of the terminal device 100. The external memory card communicates with the processor 110 through an external memory interface 120 to implement data storage functions. For example, files such as music, video, etc. are stored in an external memory card.

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

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

The audio module 170 is used to convert digital audio information into an analog audio signal output and also to convert an analog audio input into a 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 disposed in the processor 110, or a portion of the functional modules of the audio module 170 may be disposed in the processor 110.

The 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 or to handsfree talk through the speaker 170A.

A receiver 170B, also referred to as a "earpiece", is used to convert the audio electrical signal into a sound signal. When the terminal device 100 receives a call or voice message, it is possible to receive voice by approaching the receiver 170B to the human ear.

Microphone 170C, also referred to as a "microphone" or "microphone", is used to convert sound signals into electrical signals. When making a call or transmitting voice information, the user can sound near the microphone 170C through the mouth, inputting a sound signal to the microphone 170C. The terminal device 100 may be provided with at least one microphone 170C. In other embodiments, the terminal device 100 may be provided with two microphones 170C, and may implement a noise reduction function in addition to collecting sound signals. In other embodiments, the terminal device 100 may be further provided with three, four or more microphones 170C to collect sound signals, reduce noise, identify the source of sound, implement directional recording functions, etc.

The earphone interface 170D is used to connect a wired earphone. 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, a american cellular telecommunications industry association (cellular telecommunications industry association of the USA, CTIA) standard interface.

The pressure sensor 180A is used to sense a pressure signal, and may convert the pressure signal into an electrical signal. In some embodiments, the pressure sensor 180A may be disposed on the display screen 194. The pressure sensor 180A is of various types, such as a resistive pressure sensor, an inductive pressure sensor, a capacitive pressure sensor, and the like. The capacitive pressure sensor may be a capacitive pressure sensor comprising at least two parallel plates with conductive material. The capacitance between the electrodes changes when a force is applied to the pressure sensor 180A. The terminal device 100 determines the intensity of the pressure according to the change of the capacitance. When a touch operation is applied to the display 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 position of the touch from the detection signal of the pressure sensor 180A. In some embodiments, touch operations that act on the same touch location, but at different touch operation strengths, may correspond to different operation instructions. For example: and executing an instruction for checking the short message when the touch operation with the touch operation intensity smaller than the first pressure threshold acts on the short message application icon. And executing an instruction for newly creating the short message when the touch operation with the touch operation intensity being greater than or equal to the first pressure threshold acts on the short message application icon.

The gyro sensor 180B may be used to determine a motion gesture of the terminal device 100. In some embodiments, the angular velocity of the terminal device 100 about three axes (i.e., x, y, and z axes) may be determined by the gyro sensor 180B. The gyro sensor 180B may be used for photographing anti-shake. Illustratively, when the shutter is pressed, the gyro sensor 180B detects the angle of the shake of the terminal device 100, calculates the distance to be compensated by the lens module according to the angle, and allows the lens to counteract the shake of the terminal device 100 by the reverse motion, thereby realizing anti-shake. The gyro sensor 180B may also be used for navigating, somatosensory game scenes.

The air pressure sensor 180C is used to measure air pressure. In some embodiments, the terminal device 100 calculates altitude from barometric pressure values measured by the barometric pressure sensor 180C, aiding in positioning and navigation.

The magnetic sensor 180D includes a hall sensor. The terminal device 100 can detect the opening and closing of the flip cover using the magnetic sensor 180D. In some embodiments, when the terminal device 100 is a folder, the terminal device 100 may detect opening and closing of the folder according to the magnetic sensor 180D. And then according to the detected opening and closing state of the leather sheath or the opening and closing state of the flip, the characteristics of automatic unlocking of the flip and the like are set.

The acceleration sensor 180E can detect the magnitude of acceleration of the terminal device 100 in various directions (typically three axes). The magnitude and direction of gravity may be detected when the terminal device 100 is stationary. The method can also be used for identifying the gesture of the terminal equipment 100, and can be applied to applications such as horizontal and vertical screen switching, pedometers and the like.

A distance sensor 180F for measuring a distance. The terminal device 100 may measure the distance by infrared or laser. In some embodiments, the terminal device 100 may range using the distance sensor 180F to achieve fast focusing.

The proximity light sensor 180G may include, for example, a Light Emitting Diode (LED) and a light detector, such as a photodiode. The light emitting diode may be an infrared light emitting diode. The terminal device 100 emits infrared light outward through the light emitting diode. The terminal device 100 detects infrared reflected light from a nearby object using a photodiode. When sufficient reflected light is detected, it can be determined that there is an object in the vicinity of the terminal device 100. When insufficient reflected light is detected, the terminal device 100 may determine that there is no object in the vicinity of the terminal device 100. The terminal device 100 can detect that the user holds the terminal device 100 close to the ear to talk by using the proximity light sensor 180G, so as to automatically extinguish the screen for the purpose of saving power. The proximity light sensor 180G may also be used in holster mode, pocket mode to automatically unlock and lock the screen.

The ambient light sensor 180L is used to sense ambient light level. The terminal device 100 may adaptively adjust the brightness of the display 194 based on the perceived ambient light level. The ambient light sensor 180L may also be used to automatically adjust white balance when taking a photograph. The ambient light sensor 180L may also cooperate with the proximity light sensor 180G to detect whether the terminal device 100 is in a pocket to prevent false touches.

The fingerprint sensor 180H is used to collect a fingerprint. The terminal device 100 can utilize the collected fingerprint characteristics to realize fingerprint unlocking, access an application lock, fingerprint photographing, fingerprint incoming call answering and the like.

The temperature sensor 180J is for detecting temperature. In some embodiments, the terminal device 100 performs a temperature processing strategy using the temperature detected by the temperature sensor 180J. For example, when the temperature reported by the temperature sensor 180J exceeds a threshold, the terminal device 100 performs a reduction in the performance of a processor located near the temperature sensor 180J in order to reduce power consumption to implement thermal protection. In other embodiments, when the temperature is below another threshold, the terminal device 100 heats the battery 142 to avoid the low temperature causing the terminal device 100 to shut down abnormally. In other embodiments, when the temperature is below a further threshold, the terminal device 100 performs boosting of the output voltage of the battery 142 to avoid abnormal shutdown caused by low temperatures.

The touch sensor 180K, also referred to as a "touch panel". The touch sensor 180K may be disposed on the display screen 194, and the touch sensor 180K and the display screen 194 form a touch screen, which is also called a "touch screen". The touch sensor 180K is for detecting a touch operation acting thereon or thereabout. The touch sensor may communicate the detected touch operation to the application processor to determine the touch event type. Visual output related to touch operations may be provided through the display 194. In other embodiments, the touch sensor 180K may also be disposed on the surface of the terminal device 100 at a different location than the display 194.

The bone conduction sensor 180M may acquire a vibration signal. In some embodiments, bone conduction sensor 180M may acquire a vibration signal of a human vocal tract vibrating bone pieces. The bone conduction sensor 180M may also contact the pulse of the human body to receive the blood pressure pulsation signal. In some embodiments, bone conduction sensor 180M may also be provided in a headset, in combination with an osteoinductive headset. The audio module 170 may parse out a voice signal based on the vibration signal of the vocal part vibration bone piece obtained by the bone conduction sensor 180M, and implement a voice function. The application processor can analyze heart rate information based on the blood pressure beat signals acquired by the bone conduction sensor 180M, so that a heart rate detection function is realized.

The keys 190 include a power-on key, a volume key, etc. The keys 190 may be mechanical keys. Or may be a touch key. The terminal device 100 may receive key inputs, generating key signal inputs related to user settings and function controls of the terminal device 100.

The motor 191 may generate a vibration cue. The motor 191 may be used for incoming call vibration alerting as well as for touch vibration feedback. For example, touch operations acting on different applications (e.g., photographing, audio playing, etc.) may correspond to different vibration feedback effects. The motor 191 may also correspond to different vibration feedback effects by touching different areas of the display screen 194. Different application scenarios (such as time reminding, receiving information, alarm clock, game, etc.) can also correspond to different vibration feedback effects. The touch vibration feedback effect may also support customization.

The indicator 192 may be an indicator light, may be used to indicate a state of charge, a change in charge, a message indicating a missed call, a notification, etc.

The SIM card interface 195 is used to connect a SIM card. The SIM card may be contacted and separated from the terminal apparatus 100 by being inserted into the SIM card interface 195 or by being withdrawn from the SIM card interface 195. The terminal device 100 may support 1 or N SIM card interfaces, N being a positive integer greater than 1. The SIM card interface 195 may support Nano SIM cards, micro SIM cards, and the like. The same SIM card interface 195 may be used to insert multiple cards simultaneously. The types of the plurality of cards may be the same or different. The SIM card interface 195 may also be compatible with different types of SIM cards. The SIM card interface 195 may also be compatible with external memory cards. The terminal device 100 interacts with the network through the SIM card to realize functions such as call and data communication. In some embodiments, the terminal device 100 employs esims, namely: 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 one example, and that the terminal device 100 may have more or fewer components than shown in fig. 7, may combine two or more components, or may have a different configuration of components. The various components shown in fig. 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 following describes a software structure of the terminal device 100 provided in the embodiment of the present application.

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

As shown in fig. 8, the software system of the terminal device 100 may employ a layered architecture, an event driven architecture, a micro-core architecture, a micro-service architecture, or a cloud architecture. In this embodiment, taking an Android system with a layered architecture as an example, a software structure of the terminal device 100 is illustrated.

The layered architecture divides the software into several layers, each with distinct roles and branches. The layers communicate with each other through a software interface. In some embodiments, the Android system is divided into four layers, from top to bottom, an application layer, an application framework layer, an Zhuoyun row (Android run) and system libraries, and a kernel layer, respectively.

The application layer may include a series of application packages.

As shown in fig. 8, the application package may include applications for cameras, gallery, calendar, phone calls, maps, clocks, WLAN, bluetooth, music, video, short messages, etc.

The application framework layer provides an application programming interface (application programming interface, API) and programming framework for application programs of the application layer. The application framework layer includes a number of predefined functions.

As shown in fig. 8, the application framework layer may include a window manager, a content provider, a view system, a phone manager, a resource manager, a notification manager, and the like.

The window manager is used for managing window programs. The window manager can acquire the size of the display screen, judge whether a status bar exists, lock the screen, intercept the screen and the like.

The content provider is used to store and retrieve data and make such data accessible to applications. The data may include video, images, audio, calls made and received, browsing history and bookmarks, phonebooks, etc.

The view system includes visual controls, such as controls to display text, controls to display pictures, and the like. The view system may be used to build applications. The display interface may be composed of one or more views. For example, a display interface including a text message notification icon may include a view displaying text and a view displaying a picture.

The telephony manager is used to provide the communication functions of the terminal device 100. Such as the management of call status (including on, hung-up, etc.).

The resource manager provides various resources for the application program, such as localization strings, icons, pictures, layout files, video files, and the like.

The notification manager allows the application to display notification information in a status bar, can be used to communicate notification type messages, can automatically disappear after a short dwell, and does not require user interaction. Such as notification manager is used to inform that the download is complete, message alerts, etc. The notification manager may also be a notification in the form of a chart or scroll bar text that appears on the system top status bar, such as a notification of a background running application, or a notification that appears on the screen in the form of a dialog window. For example, a text message is prompted in a status bar, a prompt tone is emitted, the electronic device vibrates, and an indicator light blinks, etc.

In an embodiment of the present application, the application framework layer may further include the following modules: android keystore (android keystore), application package management service module (PMS), service management module (ServiceManager), and instrler module, wherein specific functions and working details of each module may refer to related contents in the foregoing embodiments, and are not described herein.

Android run time includes a core library and virtual machines. Android run time is responsible for scheduling and management of the Android system.

The core library consists of two parts: one part is a function which needs to be called by java language, and the other part is a core library of android.

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

The system library may include a plurality of functional modules. For example: surface manager (surface manager), media Libraries (Media Libraries), three-dimensional graphics processing Libraries (e.g., openGL ES), 2D graphics engines (e.g., SGL), etc.

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

Media libraries support a variety of commonly used audio, video format playback and recording, still image files, and the like. The media library may support a variety of audio and video encoding formats, such as MPEG4, h.264, MP3, AAC, AMR, JPG, PNG, etc.

The three-dimensional graphic processing library is used for realizing three-dimensional graphic drawing, image rendering, synthesis, layer processing and the like.

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

In the embodiment of the application, the system library may further include the following modules: the specific functions and working details of the two modules may refer to the relevant content in the foregoing embodiments, and will not be described herein.

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

The workflow of the terminal device 100 software and hardware is illustrated below in connection with capturing a photo scene.

When touch sensor 180K receives a touch operation, a corresponding hardware interrupt is issued to the kernel layer. The kernel layer processes the touch operation into the original input event (including information such as touch coordinates, time stamp of touch operation, etc.). The original input event is stored at the kernel layer. The application framework layer acquires an original input event from the kernel layer, and identifies a control corresponding to the input event. Taking the touch operation as a touch click operation, taking a control corresponding to the click operation as an example of a control of a camera application icon, the camera application calls an interface of an application framework layer, starts the camera application, further starts a camera driver by calling a kernel layer, and captures a still image or video by the camera 193.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, 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 a computer, the processes or functions described in the present application are produced in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by a wired (e.g., coaxial cable, fiber optic, digital subscriber line), or wireless (e.g., infrared, wireless, microwave, etc.). 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, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a Solid State Disk (SSD)), or the like.

Those of ordinary skill in the art will appreciate that implementing all or part of the above-described method embodiments may be accomplished by a computer program to instruct related hardware, the program may be stored in a computer readable storage medium, and the program may include the above-described method embodiments when executed. And the aforementioned storage medium includes: ROM or random access memory RAM, magnetic or optical disk, etc.

The above embodiments are only for illustrating the technical solution of the present application, and are not limiting thereof; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A key management method applied to a terminal device, the terminal device being installed with a first application, the method comprising:

the terminal equipment changes a user identification UID of the first application from a first UID to a second UID, the first application accesses a first key file according to the UID of the first application, data stored in the first key file is needed to be used when the first application executes a first service, and a file name of the first key file is generated by the terminal equipment based on the first UID;

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

the file name of the second key file is generated by the terminal equipment 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.

2. The method according to claim 1, wherein the terminal device generates a second key file based on the first key file, in particular comprising:

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

or alternatively, the first and second heat exchangers may be,

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.

3. A method according to claim 1 or 2, characterized in that before the terminal device changes the UID of the first application from a first UID to a second UID, the method further comprises:

starting up and restarting the terminal equipment after the terminal equipment finishes over-the-air upgrading OTA;

or alternatively, the first and second heat exchangers may be,

and after the terminal equipment finishes over-the-air upgrading OTA, the user logging in the terminal equipment is detected to be switched from the first user to the second user.

4. A method according to claim 1 or 2, characterized in that before the terminal device changes the UID of the first application from a first UID to a second UID, the method further comprises:

and the terminal equipment detects that the first application is started and operated.

5. A method according to claim 3, wherein the terminal device comprises an application package management service, PMS, and wherein before the terminal device generates a second key file based on the first key file, the method further comprises:

and the terminal equipment detects that the UID of the first application is changed from a first UID to a second UID through the PMS.

6. The method of claim 4, wherein the terminal device comprises a keystore service, and wherein before the terminal device generates a second key file based on the first key file, the method further comprises:

and the terminal equipment detects that the UID of the first application is changed from a first UID to a second UID through the KeyStoreservice.

7. The method according to any of claims 1-6, wherein the terminal device comprises an instrument module, the method further comprising, before the terminal device generates a second key file based on the first key file:

And the terminal equipment inquires the first UID and the second UID through an instrument module.

8. The method according to claims 1-7, characterized in that the terminal device performs the first service using the data stored in the second key file, in particular comprising:

the terminal device displays a first user interface, wherein the first user interface comprises user data, and the user data is acquired by using the data stored in the second key file.

9. The method of claims 1-8, wherein system access rights of the first application become low if a UID of the first application is changed from the first UID to the second UID.

10. The method according to any of claims 1-9, wherein after the terminal device generates the second key file based on the first key file, the method further comprises:

and the terminal equipment stores the second key file.

11. The method according to any of the claims 1-10, wherein the first application is a system application, the system application being an application preset by an operating system of the terminal device.

12. The method according to any of claims 1-11, wherein the UID of the first application is generated based on a user identity UserId, which is determined by the terminal device based on the number of users logged into the terminal device, and an application identity APPId, which is determined by the terminal device based on the package name of the first application.

13. A terminal device comprising one or more processors and one or more memories; wherein the one or more memories are coupled to the one or more processors, the one or more memories for storing computer program code comprising computer instructions that, when executed by the one or more processors, cause the terminal device to perform the method of any of claims 1-12.

14. A computer storage medium, characterized in that the computer storage medium stores a computer program comprising program instructions which, when run on a terminal device, cause the terminal device to perform the method of any of claims 1-12.