Device-level sensitive file protection method, storage medium, and electronic device

Abstract

The present application relates to the field of file-level encryption technology, and specifically to a device-level sensitive file protection method, storage medium, and electronic device. The method is applied to an electronic device, on which multiple sub-users are logged in. The method includes: evaluating the health status of multiple sub-users and obtaining the screen working status of the electronic device; obtaining the device-level class key calling policy to determine the type of device-level class key called; based on the health status of multiple sub-users, the screen working status of the electronic device, and the device-level class key calling policy, determining whether to load the device-level class key or discard the device-level class key. The present application protects device-level sensitive files by adopting device-level class keys, and determines whether to load the device-level class key to access device-level sensitive files based on the health status of each sub-user and the current device screen working status, thereby achieving secure and barrier-free access to device-level sensitive files by each sub-user, that is, achieving secure sharing of device-level sensitive files.

Description

Technical Field

[0001] The present invention relates to the technical field of file-based encryption (FBE), and in particular to a device-level sensitive file protection method, a storage medium, and an electronic device. Background Art

[0002] In the field of sensitive file protection in the terminal file system, in order to prevent terminal electronic devices such as mobile phones from being physically attacked without user authorization after being lost, such as forcibly accessing the terminal file system through USB to obtain the content of the device, resulting in the leakage of users' important privacy data files (hereinafter referred to as sensitive files), the existing industry generally uses FBE technology to perform file-level protection on sensitive files in the terminal file system. In the terminal operating system, different encryption types are set for sensitive files of different sensitivity levels in the terminal file system. For example, in Figure 1 As shown, in the Android operating system, the encryption types corresponding to sensitive files of different sensitivity levels in the terminal file system 1000 mainly include two categories: device-level encryption type and user-level encryption type, specifically including the following four categories: device-level completely non-encrypted (Global Non-Encrypted, Global NE, such as over-the-air (OTA) upgrade package) type, device-level device encryption (Global Device Encrypted, DE) type, user-level DE type, and user-level credential encryption (Credential Encrypted, CE) type. In the Huawei terminal operating system based on the Android operating system, two new encryption types for sensitive files are added, namely user-level supplementary enhanced credential encryption (Sub-Enhanced Credential Encrypted, SECE) type and user-level enhanced credential encryption (Enhanced Credential Encrypted, ECE) type. Among them, sensitive files protected by the device-level encryption type can be shared and accessed by different users on the same terminal, while sensitive files can only be accessed by the user to whom they belong.

[0003] Since sensitive files protected by user-level encryption types can only be accessed by the users to whom they belong, if a user logs in to multiple sub-users on a terminal based on usage needs, for example, a user needs to create or switch to a pure sub-user desktop as his or her own personal learning space, if the sub-user needs to access sensitive files protected by the user-level SECE / ECE types established when other sub-users log in, the sub-user cannot break through the limitation that the user-level encryption type is only bound to a single sub-user, and cannot access the sensitive file, resulting in a poor user experience. Summary of the Invention

[0004] The embodiments of the present application provide a device-level sensitive file protection method, storage medium and electronic device, which performs secondary encryption protection on the file key of the device-level sensitive file using a device-level class key, and determines whether to load the device-level class key based on the evaluation of the health status of each sub-user and the current working status of the device screen to determine whether the device-level sensitive file can be accessed and used, thereby achieving safe and barrier-free access to the device-level sensitive file by each sub-user, breaking through the limitation that sensitive files protected by the current user-level encryption type are only bound to a single sub-user.

[0005] In a first aspect, an embodiment of the present application provides a device-level sensitive file protection method, which is applied to an electronic device, where multiple sub-users are logged in to the electronic device, and the method includes: evaluating the health status of the multiple sub-users and obtaining the screen working status of the electronic device; wherein the health status is at least used to describe the security level of the sub-user; obtaining a device-level class key calling policy to determine the type of calling the device-level class key, wherein the device-level class key is used to access the device-level sensitive file; based on the health status of the multiple sub-users, the screen working status of the electronic device, and the device-level class key calling policy, determining whether to load the device-level class key or discard the device-level class key; wherein, loading the device-level class key includes copying the device-level class key to the kernel file system of the electronic device; and discarding the device-level class key includes deleting the device-level class key from the kernel file system of the electronic device.

[0006] That is, the health status of multiple sub-users and the screen working status of the electronic screen meet the conditions for secure access to device-level sensitive files, and each sub-user can access device-level sensitive files, where device-level sensitive files are file types that can be shared between sub-users who log in on the electronic device.

[0007] For example, device-level sensitive files may be screenshots, photos, and audio files saved when each sub-user logs in. The files in the electronic device that are set as device-level sensitive files can be determined or set based on the user's usage needs or habits.

[0008] In a possible implementation of the first aspect above, based on the health status of the multiple sub-users, the screen working status of the electronic device and the device-level class key calling policy, determining to load the device-level class key or to discard the device-level class key includes: when the health status of the multiple sub-users and the screen working status of the electronic device comply with the device-level class key loading policy in the device-level class key calling policy, determining to load the device-level class key; when the health status of the multiple sub-users and the screen working status of the electronic device do not comply with the device-level class key loading policy, determining to discard the device-level class key.

[0009] That is, the device-level sensitive file calling policy includes the device-level sensitive file loading policy and the device-level sensitive file discarding policy. When the health status of the sub-user and the screen working status of the electronic device meet the device-level sensitive file loading policy, it is determined to copy and load the device-level class key. Among them, the situation that does not meet the device-level sensitive file loading policy is the situation that meets the device-level sensitive file discarding policy. The situation where the health status of the sub-user and the screen working status of the electronic device do not meet the device-level sensitive file loading policy is the situation that meets the device-level sensitive file discarding. In this case, it is determined to discard and delete the loaded device-level class key.

[0010] For example, if the device-level sensitive file that the sub-user currently logged in on the electronic device needs to access is a screenshot saved by another sub-user when logged in, after loading the device-level class key for this type of device-level sensitive file, the file key used to encrypt the screenshot file can be decrypted and used, and the screenshot file can then be decrypted, allowing the sub-user currently logged in on the electronic device to access and use the screenshot file. If the device-level class key for this device-level sensitive file is discarded, the file key used to decrypt the screenshot file cannot be used, and accordingly, the screenshot file encrypted and protected by the file key cannot be accessed and used.

[0011] In a possible implementation of the first aspect above, the above method further includes: the health status is also used to describe the activity level of the sub-user; the device-level class key includes a first device-level class key, a second device-level class key, and a third device-level class key; the screen working status includes a locked screen state or an unlocked state, wherein the unlocked state includes an unlocked success state in which the unlock authentication is successfully completed after the unlock event is triggered, and an unlocked failure state in which the unlock authentication is not successfully completed.

[0012] Specifically, each sub-user's health status describes their level of activity and safety. When a sub-user's activity and safety meet health requirements, the sub-user's health status can be assessed as healthy. It is understood that each sub-user's health status can also be used to describe other sub-user status characteristics, such as their confidence level, and is not limited to the aforementioned activity and safety levels. This is not a limitation here.

[0013] Device-level class keys can be divided into multiple types of keys according to the sensitivity or sensitivity level of the device-level sensitive files they protect. It can be understood that device-level class keys are not limited to the above-mentioned first device-level class keys, second device-level class keys, and third device-level class keys, but can also include more types, which are not limited here.

[0014] The screen working state of an electronic device may include, but is not limited to, a locked screen state or an unlocked state under the current sub-user login state. In the locked screen state, the screen is locked and cannot work. The unlocked state may further include an unlock failure state where the unlock authentication fails and an unlock success state where the unlock authentication succeeds. In the unlock failure state, the screen is still locked and cannot work and can automatically enter the locked screen state when there is no operation for a period of time. In the unlock success state, the screen can work, such as clicking on the screen to start an application. The screen working state of an electronic device may also include when the current sub-user switches to another sub-user login, and there is no need to repeat the unlock authentication when the other sub-user login state is in the unlock success state. If unlock authentication is required when switching logins, when the unlock authentication succeeds, the other sub-user login state is updated and the electronic device should be in the unlock success state. When the unlock authentication fails, the other sub-user login state is updated and the electronic device should be in the unlock failure state. The screen working state of an electronic device is not limited to the locked screen state and unlock state in the various situations described above, and is not limited here.

[0015] In a possible implementation of the first aspect above, the device-level class key loading strategy includes one of the following: loading the first device-level class key when the first unlock state of the electronic device is the unlock success state after any healthy sub-user among the multiple sub-users logs in to the electronic device; loading the first device-level class key when the first unlock state after any healthy sub-user logs in to the electronic device is the unlock success state, and the first unlock state after the first sub-user currently logged in to the electronic device is the unlock success state; loading the second device-level class key or the third device-level class key when the first healthy sub-user among the multiple sub-users is currently logged in to the electronic device and the current screen working state of the electronic device is the unlock success state; loading the second device-level class key or the third device-level class key when the unlock state after any healthy sub-user logs in to the electronic device includes at least one unlock success state, and the current unlock state of the first healthy sub-user currently logged in to the electronic device is the unlock success state; wherein, the multiple sub-users include any healthy sub-user, the first healthy sub-user and the first sub-user.

[0016] That is, the loading or discarding of the first device-level class key is closely related to whether a healthy sub-user has successfully unlocked the electronic device for the first time after logging in, and whether the sub-user currently logged in to the electronic device has successfully unlocked the device for the first time; the loading or discarding of the second device-level class key or the third device-level class key is closely related to whether a healthy sub-user has logged in to the electronic device, and whether the current electronic device is in a successful unlocking state; or the loading or discarding of the second device-level class key or the third device-level class key is closely related to whether a healthy sub-user has logged in to the electronic device and is in a successful unlocking state, and whether the device is in a successful unlocking state when a healthy sub-user is currently logged in to the electronic device.

[0017] It is understandable that the device-level class key loading policy in the device-level class key calling policy is not limited to the above-mentioned cases, and may also include other situations in which it is determined that the device-level class key may be loaded, which is not limited here.

[0018] For example, if the device-level sensitive file to be protected by the first device-level class key is the screenshot saved by the above-mentioned screenshot, when a healthy sub-user logs in to the electronic device and successfully unlocks the electronic device for the first time, the first device-level class key can be loaded to access and use the screenshot.

[0019] In a possible implementation of the first aspect above, the evaluating the health status of the multiple sub-users includes: obtaining the health status parameters of the first sub-user among the multiple sub-users, wherein the health status parameters are at least used to calculate the activity level and safety level of the sub-user; and when the health status parameters of the first sub-user meet a preset threshold condition, evaluating the sub-user as a healthy sub-user.

[0020] The health status parameters include the sub-user creation time of the first sub-user, the total number of unlocking attempts, the number of unlocking failures or the number of unlocking successes when logging into the first sub-user on the electronic device, and the total unlocking active time; wherein, the total number of unlocking attempts is the number of times the unlocking event is triggered, the number of unlocking failures is the number of times the unlocking failure state occurs, and the number of unlocking successes is the number of times the unlocking success state occurs.

[0021] That is, the sub-user's activity and security are calculated using health status parameters, thereby assessing the sub-user's health status. It is understood that health status parameters are not limited to the aforementioned sub-user creation time, total number of unlock attempts, number of failed or successful unlocks, and total unlock activity time. They may also include other characteristics that can be used to calculate activity, security, or other status characteristics, which are not limited here.

[0022] For example, the activity level of a sub-user can be calculated by the sub-user creation time and the total unlocking active time, to determine whether the sub-user is active or inactive; the security level of a sub-user can be calculated by the total number of unlocking attempts, unlocking failures, or unlocking successes, to determine whether the sub-user is safe or risky.

[0023] In a possible implementation of the first aspect above, the evaluating the health status of the multiple sub-users further includes: when the ratio of the total unlocking activity time to the first sub-user creation time is greater than or equal to a preset activity threshold, determining that the activity level of the first sub-user is active; when the total number of unlocking attempts is greater than or equal to a preset number threshold, and the ratio of the number of unlocking failures to the total number of unlocking attempts is less than or equal to a preset risk rate threshold, determining that the safety level of the first sub-user is safe; or when the ratio of the number of unlocking successes to the total number of unlocking attempts is greater than or equal to a preset success rate threshold, determining that the safety level of the first sub-user is safe; when the first sub-user is active and safe, determining that the first sub-user is a healthy sub-user.

[0024] That is, the health status of each sub-user can be assessed by integrating multiple status characteristics. For example, the sub-user's activity level and safety level can be integrated to assess whether the health status is healthy or unhealthy. It is understood that the health status assessment of each sub-user is not limited to integrating the above-mentioned activity level and safety level. It can also be assessed by integrating more or fewer status characteristics or other status characteristics, and this is not limited here.

[0025] In a possible implementation of the above-mentioned first aspect, the first device-level class key is a device-level credential encryption class key, the second device-level class key is a device-level enhanced encryption class key, and the third device-level class key is a device-level comprehensive encryption class key.

[0026] In a second aspect, an embodiment of the present application provides a computer-readable storage medium having instructions stored thereon, which, when executed on a computer, causes the computer to execute the above-mentioned device-level sensitive file protection method.

[0027] In a third aspect, an embodiment of the present application provides an electronic device comprising one or more processors; one or more memories; wherein the one or more memories store one or more programs, and when the one or more programs are executed by the one or more processors, the electronic device executes the above-mentioned device-level sensitive file protection method.

[0028] In a fourth aspect, an embodiment of the present application provides a computer program product, including a computer program / instruction, which implements the above-mentioned device-level sensitive file protection method when executed by a processor. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Figure 1 The figure shows a schematic diagram of the terminal file system structure on an electronic device with multiple sub-users provided in an embodiment of the present application.

[0030] Figure 2 Shown is an exemplary comparison table of sensitive file encryption types under different operating systems provided in an embodiment of the present application.

[0031] Figure 3 The figure shows a flow chart of a device-level sensitive file protection method provided in an embodiment of the present application.

[0032] Figure 4 a is a schematic diagram of the process interface for creating / logging in a sub-user provided in an embodiment of the present application.

[0033] Figure 4 b is a schematic diagram of the process interface for creating / logging in a sub-user provided in an embodiment of the present application.

[0034] Figure 4c is a schematic diagram of the process interface for creating / logging in a sub-user provided in an embodiment of the present application.

[0035] Figure 4 d is a schematic diagram of the process interface for creating / logging in a sub-user provided in an embodiment of the present application.

[0036] Figure 5 a shows Figure 4 Schematic diagram of the interface corresponding to operation ① in d.

[0037] Figure 5 b shows Figure 4 Schematic diagram of the interface corresponding to operation ② in d.

[0038] Figure 6 The figure shows a schematic block diagram of the relevant software structure for managing the health status of sub-users in the mobile phone 100 provided in an embodiment of the present application.

[0039] Figure 7 Shown is a schematic diagram of health status parameters of a sub-user 100-n and corresponding health status assessment results provided in an embodiment of the present application.

[0040] Figure 8 The figure shows a flow chart of a method for evaluating the health status of a sub-user 100-n provided in an embodiment of the present application.

[0041] Figure 9 The figure shows a block diagram of the relevant software structure for managing device-level class keys in the mobile phone 100 provided in an embodiment of the present application.

[0042] Figure 10 The figure shows a flow chart of a method for managing device-level class keys provided in an embodiment of the present application.

[0043] Figure 11 Shown is a structural diagram of a mobile phone 100 provided in an embodiment of the present application.

[0044] Figure 12 Shown is a software structure block diagram of a mobile phone 100 provided in an embodiment of the present application. DETAILED DESCRIPTION

[0045] In order to make the purpose, technical solutions and advantages of this application clearer, the technical solutions of the embodiments of this application are further described in detail below in combination with the accompanying drawings and implementation plans.

[0046] above Figure 1 The figure shows a schematic diagram of a terminal file system with multiple sub-users provided in an embodiment of the present application. Figure 1As shown, a user has multiple sub-users 100-n on electronic device 100, including sub-users 100-1 to 100-n. In the prior art, when a user switches from sub-user 100-1 to sub-user 100-2 to log in, sub-user 100-2 cannot access the device-level sensitive files generated by the user on sub-user 100-1, such as photos taken, stored screenshots, downloaded documents, etc. This is mainly due to the fact that such sensitive files still use user-level encryption in the prior art, and the user-level encryption type is only bound to a single sub-user. Therefore, there are still many inconveniences when users switch between the sub-users they created. Among them, device-level sensitive files can be understood as sensitive file types that can be shared among sub-users based on user usage needs.

[0047] like Figure 1 As shown, in the terminal file system of the electronic device 100, the encryption types for protecting sensitive files of different sensitivity levels include: the device-level non-encrypted (Non-Encrypted, NE) class 1010 that has been set in the prior art, such as remote wireless (Over The Air, OTA) upgrade package files, etc.; the device-level device encryption (Device Encrypted, DE) class 1011, such as the user profile of the application (Application, APP); the user-level DE class 1021, such as Bluetooth pairing data, alarm clock, ringtone, etc.; the user-level credential encryption (Credential Encrypted, CE) class 1022, such as downloaded documents, stored screenshots, etc.; the user-level enhanced encryption (Sub-Enhanced Credential Encrypted, SECE) class 1023, such as sports data recorded by sports APP, etc.; the user-level full encryption (Enhanced CredentialEncrypted (ECE) class 1024, such as contacts, wallets, account information, etc.; and the device-level CE class 1012, device-level SECE class 1013, and device-level ECE class 1014 constructed in this application. Among them, the sensitive files protected by the device-level CE class 1012 and the user-level CE class 1022, the device-level SECE class 1013 and the user-level SECE class 1023, and the device-level ECE class 1014 and the user-level ECE class 1024 can be the same or different. The specific settings can be made based on the user's usage requirements and are not limited here.

[0048] To solve the above technical problems, the present application provides a device-level sensitive file protection method, constructs the above-mentioned device-level encryption types for protecting device-level sensitive files, such as device-level CE class 1012, device-level SECE class 1013, and device-level ECE class 1014. The present application uses a device-level class key to perform secondary encryption protection on the file key of the device-level sensitive file, and then determines whether to load the device-level class key based on the evaluation of the health status of each sub-user and the current device screen working status to decrypt the file key, thereby accessing and using the protected device-level sensitive file. Therefore, the present application breaks through the limitation that the user-level encryption type is only bound to a single sub-user, allowing users to access various types of device-level sensitive files generated when logging in using other sub-users if the sub-user health status meets security requirements. At the same time, the present application performs dual protection of the file key and the device-level class key on the device-level sensitive file, thereby improving the security of the device-level sensitive file and enabling each sub-user to have safe and barrier-free access to the device-level sensitive file, greatly improving the user experience of switching logins between multiple sub-users.

[0049] It is understood that the electronic device 100 may include, but is not limited to, laptop computers, desktop computers, tablet computers, smart speakers, mobile phones, wearable devices, head-mounted displays, large-screen televisions, large-screen monitors, and other large-screen display devices, in-vehicle computers, in-vehicle voice navigation and other in-vehicle intelligent systems, as well as intelligent robots, portable music players, reading devices, and other electronic devices that have one or more processors embedded or coupled thereto and can access the Internet. For ease of description, the following description uses a mobile phone as an example of the electronic device 100.

[0050] It is understood that the operating system of the mobile phone 100 can be an Android operating system, an operating system further developed based on the native Android system (such as Huawei's EMUI system), an iOS operating system, and a Hongmeng operating system, etc., without limitation. For ease of description below, the operating system of the mobile phone 100 is taken as an example of the Android operating system.

[0051] To facilitate understanding, the following briefly introduces the concepts related to the sensitive file encryption types in the above-mentioned Android operating system.

[0052] The DE class refers to a sensitive file encryption type that can be accessed and used after the mobile phone 100 is turned on, including operations such as opening, creating, and writing to protected sensitive files without user authentication.

[0053] CE type refers to a sensitive file encryption type that requires user unlock authentication when the mobile phone 100 is first unlocked after powering on before the key can be loaded for access and use. Subsequent access after the first unlock does not require user authentication. In other words, after the first unlock, sensitive files protected by CE type can be directly accessed and used whether the mobile phone 100 is locked or unlocked. Among them, user unlock authentication methods include but are not limited to entering a PIN code, verifying fingerprints or facial recognition.

[0054] The SECE class refers to a sensitive file encryption type enhanced on the basis of the CE solution. This refers to a sensitive file encryption type that requires user authentication when the mobile phone 100 is first unlocked, and can only be accessed by loading a key when the mobile phone 100 is unlocked. It is understood that when the mobile phone 100 is locked, sensitive files protected by the SECE class cannot be opened, but new files can be created and written to. When the electronic device 100 is unlocked, sensitive files protected by the SECE class can be opened, created, and written to.

[0055] The ECE class is a sensitive file encryption type that further enhances the SECE solution. This type of sensitive file encryption requires user authentication when the phone 100 is first powered on, and can only be accessed by loading a key when the phone 100 is unlocked. It is understood that sensitive files protected by the ECE class cannot be opened, created, or written to when the phone 100 is locked; only when the electronic device 100 is unlocked can sensitive files protected by the ECE class be opened, created, or written to.

[0056] It is understood that the device-level sensitive file protection method of this application is also applicable to other operating systems, such as Apple's iOS system, and is not limited here. Among them, in the iOS system, the sensitive file encryption types include four major types: ABCD, such as Figure 2 As shown in the figure, as an example, by comparing the protection methods of the four types of sensitive files, ABCD, in the iOS system with the protection methods of the four types of sensitive files, the corresponding relationship between the encryption types of sensitive files in the iOS system and the Android operating system is as follows: DE corresponds to D; CE corresponds to C; SECE corresponds to B; and ECE corresponds to A. This will not be repeated here.

[0057] The following will be based on Figure 1 The terminal file system shown in the figure introduces the device-level sensitive file protection solution of the present application in detail in combination with the accompanying drawings and specific embodiments.

[0058] Example 1

[0059] Figure 3The schematic flow chart of the device-level sensitive file protection method of the present application is shown. As an example, Figure 3 The steps shown are implemented in the mobile phone 100, wherein the creation of the sub-user is performed by the processor of the mobile phone 100 by running the application; the evaluation, judgment and other steps are performed by the processor of the mobile phone 100 by running the program module.

[0060] like Figure 3 As shown, the implementation steps of the above device-level sensitive file protection method include:

[0061] 301: Create / login sub-user 100-n.

[0062] Generally, when the mobile phone 100 is turned on and used for the first time, it is necessary to bind a device account. The binding information on the device account generally includes but is not limited to the mobile phone number, wallet account, etc. corresponding to the SIM card installed in the mobile phone 100. In addition, in the settings interface of the mobile phone 100, multiple sub-users can be created and logged in, where each sub-user has an independent desktop setting. When the sub-user logs in, the sub-user can install the same or different applications as other sub-users, and set the same or different unlock passwords, etc. It should be noted that if the bound device account is not changed or cancelled, the multiple sub-users logged in on the mobile phone 100 generally belong to the same device account. As an example, the process of creating / logging in a sub-user on the mobile phone 100 can refer to Figure 4 a- Figure 4 As shown in d.

[0063] Figure 4 a- Figure 4 d shows a schematic diagram of the process interface for creating / logging in a sub-user on the mobile phone 100. Figure 4 As shown in Figure a, when a user is using the mobile phone 100, the user needs to use another clean desktop to meet his or her usage needs at a certain moment or within a certain period of time. For example, the user needs a clean desktop without various games, entertainment, chat or payment applications to install learning applications for non-interference learning, or needs a clean desktop to provide a non-interference device desktop environment for children to study online. Figure 4 As shown in a-4d, when the user needs to create a sub-user or switch to log in to another sub-user desktop, he can enter the setting application on the mobile phone 100 desktop by clicking on the setting application on the mobile phone 100 desktop. Figure 4 b shows the settings interface. The user continues to click "Users and Accounts" to enter Figure 4 c shows the user and account interface, the user continues to click "Multi-user" to enter Figure 4 d shows a multi-user interface, in Figure 4 In the multi-user interface shown in c, the user can click "Add User" to perform operation ①, or click "Sub-user 100-2" or "Sub-user 100-3" to perform operation ②.

[0064] Among them, operation ① is to create a sub-user operation. After operation ①, a pop-up window will appear on the mobile phone 100. Figure 5 In the operation box shown in a, you can learn about the related functions of creating a new user in this operation box. You can also enter the custom name of the sub-user to be created in the "Nickname". After entering, click "Add" to create the sub-user and then start the new sub-user's related information and network and other basic settings. Click "Cancel" to cancel the creation of the sub-user and return Figure 4 It can be understood that the process of creating a sub-user can complete the login of the newly created sub-user, that is, when the new sub-user is created, the mobile phone 100 has switched to the new sub-user desktop.

[0065] Operation ② is to switch the login sub-user. After operation ②, a pop-up window will appear on the mobile phone 100. Figure 5 b) will ask the user to confirm "whether to switch to a new user". Click "Confirm" to switch to the selected sub-user login. Click "Cancel" to cancel the sub-user switch operation and return to the Figure 4 The interface shown in d.

[0066] I understand. Figure 4 The three sub-users shown in d (i.e., sub-user 100-1, sub-user 100-2, and sub-user 100-3) do not constitute a limit on the number of sub-users. In other implementations, the user can create any number of sub-users on the mobile phone 100, and there is no limit here. In other embodiments, Figure 4 Sub-user 100-1 in d can also be displayed as "Device Owner", with the authority of device administrator. He can manage the creation or deletion of other sub-users (such as sub-user 100-2 and sub-user 100-3). The names and permissions of other sub-users (such as sub-user 100-2 and sub-user 100-3) can be customized based on user preferences or usage habits, and there are no restrictions here.

[0067] 302: Evaluate and update the health status of sub-user 100-n, and update the screen operating status of mobile phone 100 when the current sub-user is logged in. The processor of mobile phone 100 determines the health attributes of each sub-user 100-n, such as activity level and security level, based on the data related to lock / unlock events triggered by each sub-user's login status, and evaluates the health status of each sub-user based on these health attributes.

[0068] It can be understood that the screen working status of the mobile phone 100 includes the screen non-working state after locking the screen when logging in to a certain sub-user, the screen non-working state after unlocking fails, the screen working state after unlocking successfully, and the screen non-working state after unlocking fails or the screen working state after unlocking successfully that may appear after re-unlocking authentication when switching to another sub-user to log in when the screen is in a working state after unlocking successfully.

[0069] For example, the activity level of a sub-user can be determined by the length of time the sub-user was created and the total unlocking active time, and the security level of the sub-user can be determined by the total number of unlocking attempts and unlocking failures updated during the sub-user's login status. The software structure involved in evaluating the health status of sub-users 100-n and the evaluation method for the sub-user's health status will be described in detail below and will not be repeated here.

[0070] 303: Based on the health status of each sub-user, the current screen working status of the mobile phone 100, and the obtained device-level class key calling policy, determine whether to load or discard the device-level class key in the kernel file system of the mobile phone 100. Among them, the device-level class key calling policy includes a loading policy and a discarding policy. It can be understood that the situation where the processor of the mobile phone 100 determines that it does not comply with the device-level class key loading policy is a situation that complies with the device-level class key discarding policy. When the health status of each sub-user and the current screen working status of the mobile phone 100 comply with the loading policy in the device-level class key calling policy, the processor of the mobile phone 100 determines to load the device-level class key and proceeds to 304; when the health status of each sub-user and the current screen working status of the mobile phone 100 comply with the discarding policy in the device-level class key calling policy, the processor of the mobile phone 100 determines to discard the device-level class key and proceeds to 305.

[0071] It is understood that the device-level class key invocation policy can be set and upgraded or updated based on the user's sub-user login habits. The device-level class key invocation policy varies for different encryption types. The health status of each sub-user and the current screen operating status of the mobile phone 100 are the results of the implementation of step 302. The software structure involved in managing device-level class keys and the management method of device-level class keys will be described in detail below and will not be repeated here.

[0072] 304: Load the device-level class key and decrypt it to obtain the file key, making the device-level sensitive file accessible and usable. If the judgment result or the execution instruction obtained in step 303 is to load the device-level class key, the processor of mobile phone 100 controls access to the storage path of the device-level class key, loads the device-level class key into the kernel file system, and decrypts the file key. The decrypted file key is then used to decrypt the protected device-level sensitive file data.

[0073] It can be understood that after the protected device-level sensitive files are decrypted, the sub-user currently logged in on mobile phone 100 can access the device-level sensitive file data generated when other sub-users log in. For example, after loading the device-level class key for decryption, the currently logged-in sub-user 100-2 can access the screenshots (device-level CE class), historical motion data (device-level SECE class) or stored contacts (device-level ECE class) stored when sub-user 100- is logged in.

[0074] 305: Discard the device-level class key, the file key is unusable, and the device-level sensitive file is inaccessible. If the judgment result or the execution instruction obtained in step 303 is to discard the device-level class key, the processor of the mobile phone 100 controls the deletion of the loaded device-level class key from the kernel file system.

[0075] It is understood that after the device-level class key is deleted, the corresponding file key is also deleted. Therefore, the currently logged-in sub-user cannot access device-level sensitive file data generated by other sub-users when logged in. For example, after the kernel file system of mobile phone 100 discards the device-level class key decryption, the currently logged-in sub-user 100-2 cannot access device-level CE-class sensitive files created by other sub-users, such as screenshots stored when sub-user 100- logged in; the currently logged-in sub-user 100-2 also cannot access device-level SECE-class files created by other sub-users, such as historical sports data; or device-level ECE-class sensitive files created by other sub-users, such as stored contacts.

[0076] Let's combine Figure 6-9 The software structure involved in evaluating the health status of the sub-user 100 - n and the evaluation method of the sub-user health status are introduced in detail.

[0077] Figure 6 FIG1 shows a schematic block diagram of the software structure for managing the health status of sub-users in the mobile phone 100. Figure 6 As shown, the relevant software structure for managing the health status of sub-users includes but is not limited to a user management module 1100, a lock screen / unlock module 1200, a sub-user status management module 1300, a class key management module 1400, and a kernel file system 1500. The sub-user status management module 1300 includes but is not limited to a sub-user health status management module 1310 and a current screen working status management module 1320; the class key management module 1400 includes but is not limited to a user-level class key management module 1410 and a device-level class key management module 1420.

[0078] Specifically, the user management module 1100 is used to perform management operations such as sub-user creation, login switching, and deletion. The user management module 1100 is also used to execute the sub-user to modify the lock screen / unlock password, fingerprint information, face recognition information and other passwords, and verify the lock screen / unlock password, fingerprint information, face recognition information and other passwords. The user management module 1100 is also used to record and update data such as user creation time. Among them, the creation and login switching process of sub-users can be referred to Figure 4 a- Figure 4 d. Figure 5 a- Figure 5 b and related descriptions will not be repeated here.

[0079] The lock screen / unlock module 1200 is used to obtain various trigger events on the mobile phone 100 and determine whether the type of the obtained trigger event is a lock screen or unlock event. When the trigger event is an unlock event, the lock screen / unlock module 1200 is also used to determine whether the unlock event is successful and send the lock screen / unlock related data to the sub-user status management module 1300. It will be understood that if the trigger event is not a lock screen / unlock event, the lock screen / unlock module 1200 will not process the trigger event.

[0080] The sub-user status management module 1300 is used to perform management operations such as evaluating and updating the status attributes of a sub-user. The sub-user health status management module 1310 is used to perform management operations such as evaluating and updating the user's health status, and the current screen operating status management module 1320 is used to perform management operations such as real-time updating of the current screen operating status of the mobile phone 100. It will be understood that when the screen operating status of the mobile phone 100 is updated, lock screen / unlock related data can be synchronously updated to the sub-user health status management module 1310 for the module to evaluate and update the sub-user's health status. Lock screen / unlock related data includes, for example, the total unlock active duration, total number of unlock attempts, number of unlock failures, or number of unlock successes of the sub-user 100-n. The following examples illustrate how the sub-user health status management module 1310 evaluates the health status of the sub-user 100-n.

[0081] Figure 7 FIG. 1 shows a schematic diagram of the health status parameters of the sub-user 100-n and the corresponding health status evaluation results. Figure 7As shown, after the lock screen / unlock module 1200 determines that the trigger event is a lock screen / unlock event, the corresponding lock screen / unlock data is synchronously updated to the sub-user status management module 1300. After obtaining the corresponding lock screen / unlock data, the sub-user health status management module 1310 in the sub-user status management module 1300 updates the health status parameters of the sub-user 100-n and evaluates the health status of the sub-user 100-n. After obtaining the corresponding lock screen / unlock data, the current screen working status management module 1320 updates the current screen working status of the sub-user 100-n. The health status parameters of the sub-user 100-n include, but are not limited to, the sub-user creation time and lock screen / unlock related data described above. The lock screen / unlock related data includes, as exemplary health status parameters, the total unlock active time, the total number of unlock attempts, and the number of unlock failures.

[0082] Specifically, the sub-user health status management module 1310 can determine the activity level of the corresponding sub-user 100-n based on the sub-user creation time and the total unlocking active time. For example, the activity rate of the corresponding sub-user 100-n can be determined by calculating the percentage ratio of the total unlocking active time to the sub-user creation time, and the activity rate can be compared with a preset activity rate threshold to determine the activity level of the sub-user 100-n. The security level of the corresponding sub-user 100-n can be determined based on the total number of unlocking attempts and the number of unlocking failures. For example, the risk rate of the corresponding sub-user 100-n can be determined by calculating the percentage ratio of the number of unlocking failures to the total number of unlocking attempts, and the risk rate can be compared with a preset risk rate threshold to determine the security level of the sub-user 100-n. At the same time, to improve the accuracy of the judgment, a number threshold can be set for the total number of unlocking attempts to increase the reference value of the above-mentioned activity rate and risk rate data.

[0083] It is understood that if the total number of unlock attempts is low, using the above-mentioned activity rate and risk rate to determine the activity and security level of a sub-user will have a high probability of misjudgment. Therefore, in this case, the calculation results of the above-mentioned activity rate and risk rate are of little or no reference value. For example, if the total number of unlock attempts for sub-user 100-n is set to 5 times, that is, the sub-user health status management module 1310 will only perform a health status assessment on sub-user 100-n when the total number of unlock attempts under login by sub-user 100-n is ≥5 times. If the total number of unlock attempts is ≥5 times, the lower limit threshold of the activity rate can be preset to 50%, and the lower limit threshold of the risk rate can be preset to 70%. That is, if the activity rate of a sub-user is ≥50%, the activity level is active, otherwise it is inactive, and if the risk rate is ≥70%, the security level is risky, otherwise it is safe.

[0084] It is understood that the sub-user health status management module 1310 can, if the total number of unlock attempts is sufficient, determine the activity level and security level of the sub-user 100-n and then evaluate the health status of the sub-user 100-n. For example, if the activity level of the sub-user 100-n is active and the security level is safe, the health status of the sub-user 100-n can be evaluated as healthy; if the activity level of the sub-user 100-n is inactive or the security level is risky, the health status of the sub-user 100-n can be evaluated as unhealthy.

[0085] For example, Figure 7 As shown, sub-user 100-1 was created 30 days ago, has been active for 29 days, has attempted to unlock for 100 times, and has failed to unlock for 0 times. Therefore, the activity rate of sub-user 100-1 is calculated to be 96.7%, which is greater than 50%, indicating that it is active. The risk rate of sub-user 100-1 is 0%, which is less than 70%. Therefore, sub-user 100-1 is active and safe, and the sub-user health status management module 1310 can evaluate sub-user 100-1 as a healthy sub-user.

[0086] Similarly, the creation time of sub-user 100-2 is 30 days, the total unlocking active time is 15 days, the total number of unlocking attempts is 50 times, and the number of unlocking failures is 20 times. Then the activity rate of sub-user 100-2 is 50%, which is inactive; the risk rate of sub-user 100-2 is 40%<70%, which is safe; therefore, the sub-user health status management module 1310 can evaluate sub-user 100-2 as a sub-user in an unhealthy state.

[0087] In addition, since the total number of unlock attempts of the sub-user 100 - 3 is 1<5, the sub-user health status management module 1310 may temporarily not evaluate the health status of the sub-user 100 - 3 or temporarily mark the sub-user 100 - 3 as an unhealthy sub-user.

[0088] In other embodiments, other health status parameters may be used to calculate status characteristic values ​​such as the activity rate and risk rate of the sub-user 100-n. For example, the risk rate of the corresponding sub-user 100-n may be determined by calculating the percentage ratio of the number of successful unlocking attempts to the total number of unlocking attempts, and a corresponding status characteristic value threshold may be set as a reference to evaluate the health status of the sub-user 100-n. This is not limited here.

[0089] It is understood that after the unlock event is triggered, the mobile phone 100 needs to undergo user unlock authentication before it can be successfully unlocked. As mentioned above, the user unlock authentication methods include but are not limited to unlocking by entering a PIN code, unlocking by entering a power-on password, unlocking by verifying a fingerprint, or unlocking by face recognition. It is understood that in order to avoid misjudging the number of unlock failures, weights can also be set for the above-mentioned various unlock authentication methods to calculate the number of unlock failures. For example, the weight coefficient for unlocking by face recognition is set to 0.2, the weight coefficient for unlocking by verifying a fingerprint is set to 0.3, and the weight coefficient for unlocking by entering a PIN code or entering a power-on password is set to 0.5. The number of unlocks corresponding to various unlock authentication methods is calculated and multiplied by the weight coefficient, and the sum of the summed results is rounded to obtain the comprehensive number of unlock failures. There is no limitation here.

[0090] The class key management module 1400 is used to determine and generate class key loading or discarding instructions, which are then sent to the kernel file system 1500 for execution. Specifically, the user-level class key management module 1410 is used to perform management operations such as loading or discarding class keys corresponding to user-level encryption types (including user-level CE / SECE / ECE classes, etc.); and the device-level class key management module 1420 is used to perform management operations such as loading or discarding device-level class keys corresponding to device-level encryption types such as device-level CE / SECE / ECE classes based on the sub-user health status updated by the sub-user status management module 1300, the current screen operating state of the mobile phone 100, and the device-level class key call policy. It will be understood that for device-level class keys of the aforementioned device-level encryption types, when the sub-user health status and current screen operating state meet the loading policy judgment conditions in the device-level class key call policy corresponding to each device-level encryption type, the device-level class key management module 1420 generates a device-level class key loading instruction; otherwise, a device-level class key discarding instruction is generated.

[0091] As an example, in a scenario where the security of the mobile phone 100 is low, the device-level class key call policy corresponding to each device-level encryption type can be set as follows:

[0092] ① For device-level CE class 1012, if a healthy sub-user has unlocked the mobile phone 100, the device-level class key management module 1420 generates a device-level class key loading instruction corresponding to the device-level CE class 1012. For example, after the device-level class key corresponding to the device-level CE class 1012 is loaded, the currently logged-in sub-user 100-1 can access the screenshots stored when other sub-users log in; if the mobile phone 100 has not been unlocked by a healthy sub-user, the device-level class key management module 1420 generates a discarding instruction for the device-level class key corresponding to the device-level CE class 1012. For example, after the device-level class key corresponding to the device-level CE class 1012 is discarded, the currently logged-in sub-user 100-1 cannot access the screenshots stored when other sub-users log in.

[0093] ② For device-level SECE class 1013 and device-level ECE class 1014, if the sub-user 100-1 currently logged in by the mobile phone 100 is in a healthy state and the current mobile phone 100 is unlocked successfully, the device-level class key management module 1420 generates a loading instruction for the device-level class key corresponding to the device-level SECE class 1013 and the device-level ECE class 1014. For example, after the device-level class key is loaded, the sub-user 100-1 currently logged in can access the historical motion data stored when logging in using other sub-users; if the sub-user 100-1 currently logged in by the mobile phone 100 is in an unhealthy state or a pending state, the device-level class key management module 1420 generates a discarding instruction for the sensitive file class key corresponding to the device-level SECE class 1013 and the device-level ECE class 1014. For example, after the device-level class key is discarded, the sub-user 100-1 currently logged in cannot access the historical motion data stored when logging in using other sub-users.

[0094] In a scenario where the mobile phone 100 is configured with a higher security scenario, a dual authentication strategy may be adopted. As an example, the device-level class key call strategy corresponding to the device-level encryption type may be set as follows:

[0095] ① For device-level CE class 1012, if other healthy sub-users have successfully unlocked the phone 100 for the first time after it is turned on, and the currently logged-in sub-user 100-1 has successfully unlocked the phone for the first time, the device-level class key management module 1420 generates a loading instruction for the device-level class key corresponding to the device-level CE class 1012; if no other healthy sub-users have successfully unlocked the phone 100 for the first time after it is turned on, or the currently logged-in sub-user 100-1 has failed to unlock the phone for the first time, the device-level class key management module 1420 generates a discarding instruction for the device-level class key corresponding to the device-level CE class 1012.

[0096] ② For device-level SECE class 1013 and device-level ECE class 1014, that is, if the mobile phone 100 has been unlocked by a healthy sub-user and the currently logged-in sub-user 100-1 is in a healthy state, the device-level class key management module 1420 loads the device-level class keys corresponding to the device-level SECE class 1013 and the device-level ECE class 1014. For example, after the device-level class keys are loaded, the currently logged-in sub-user 100-1 can access the historical motion data stored when logging in using other sub-users; if the mobile phone 100 has not been unlocked by a healthy sub-user or the currently logged-in sub-user 100-1 is in an unhealthy state, the device-level class key management module 1420 discards the device-level class keys corresponding to the device-level SECE class 1013 and the device-level ECE class 1014. For example, after the device-level class keys are discarded, the currently logged-in sub-user 100-1 cannot access the historical motion data stored when logging in using other sub-users.

[0097] The kernel file system 1500 is configured to receive and execute user-level class key or device-level class key load / discard instructions sent by the user-level class key management module 1410 or the device-level class key management module 1420. It will be appreciated that the kernel file system 1500 can load a class key based on an access path to a storage location storing the class key in the terminal file system 1000, and that discarding a class key involves deleting the loaded class key from the kernel file system 1500.

[0098] Based on the above Figure 6 The structure shown, Figure 8 FIG. 1 shows a flow chart of a method for evaluating the health status of a sub-user 100-n. Figure 8 As shown, the process includes:

[0099] 801: Obtain trigger events. The processor of the mobile phone 100 runs the corresponding program to execute the functions of the lock screen / unlock module 1200 and obtain trigger events on the mobile phone 100. Trigger events on the mobile phone 100 include lock screen / unlock events triggered by operating the power on / off button of the mobile phone 100, lock screen / unlock events triggered by touching the touch panel of the mobile phone 100, power on events, power off events, etc., and screenshot events triggered by operating the power on / off button and volume button of the mobile phone 100, etc., which are not further described here.

[0100] 802: Determine whether the acquired trigger event is an unlock event. The processor of mobile phone 100 executes the corresponding program to execute the functions of lock screen / unlock module 1200, and determines whether the acquired trigger event on mobile phone 100 is an unlock event. Unlock events include but are not limited to pressing the power button to unlock, clicking the lock screen / unlock application to unlock, etc. If the trigger event is an unlock event, execute 803; if not, execute 806.

[0101] 803: Determine whether the unlock event was successful. The processor of mobile phone 100 runs the corresponding program to execute the functions of lock screen / unlock module 1200 to determine whether the unlock event was successful. It can be understood that after the unlock event occurs, if the user successfully opens the mobile phone 100 interface through the correct PIN code authentication, fingerprint authentication, or facial recognition authentication, the unlock event is successful; otherwise, the unlock is unsuccessful. If the unlock event is successful, execute 804; if not, execute 805.

[0102] 804: Update the total number of unlock attempts. The processor of mobile phone 100 executes the corresponding program to perform the functions of sub-user health status management module 1310, adding one to the total number of unlock attempts for the currently logged-in sub-user, thus updating the total number of unlock attempts for the currently logged-in sub-user. After this step, the process continues with 809.

[0103] 805: Update the total number of unlock attempts and the number of unlock failures. The processor of mobile phone 100 executes the corresponding program to perform the functions of sub-user health status management module 1310, adding one to the total number of unlock attempts and one to the recorded number of unlock failures for the currently logged-in sub-user, and updating the total number of unlock attempts and unlock failures for the currently logged-in sub-user. After this step, execution continues with 809.

[0104] 806: Determine whether the acquired trigger event is a lock screen event. The processor of mobile phone 100 executes the corresponding program to execute the functions of lock screen / unlock module 1200, and determines whether the acquired trigger event on mobile phone 100 is a lock screen event. Lock screen events include but are not limited to pressing the power button to lock the screen, clicking the lock screen / unlock application to lock the screen, and the automatic lock screen of mobile phone 100 after a period of no input. If the trigger event is a lock screen event, execute 807; if not, execute 808.

[0105] 807: Update total unlock active time. The processor of mobile phone 100 executes the corresponding program to execute the functions of sub-user health status management module 1310, adding the unlock active time before the current lock screen to the recorded total unlock active time of the currently logged-in sub-user, thus updating the total unlock active time of the currently logged-in sub-user. After this step, the process continues with 809.

[0106] 808: End this process. The processor of the mobile phone 100 runs the corresponding program to perform the functions of the lock screen / unlock module 1200, does not process non-lock screen / unlock events, and ends this process.

[0107] 809: Update the sub-user creation time and determine the sub-user's activity and security level. The processor of mobile phone 100 runs the corresponding program to execute the functions of sub-user health status management module 1310. It adds the time from the last update to the recorded creation time of the currently logged-in sub-user, or calculates the creation time of the currently logged-in sub-user based on the time difference between the creation time of the currently logged-in sub-user and the current time.

[0108] 810: Evaluate the health status of the sub-user, update the sub-user health status and current screen working status. The processor of the mobile phone 100 runs the corresponding program to execute the function of the sub-user health status management module 1310, and evaluates the health status of the sub-user based on the total number of unlock attempts, unlock failures, total unlock active time, and sub-user creation time updated in steps 804, 805, 807 and step 809. The sub-user health status evaluation method refers to the above Figure 6The description of the neutron user health status management module 1310 is not repeated here. In addition, the processor of the mobile phone 100 runs the corresponding program to execute the function of the current screen working state management module 1320, and updates the current screen working state of the mobile phone 100 based on this lock screen / unlock event. It can be understood that the current screen working state of the mobile phone 100 includes two states: lock screen state and unlock state. Figure 7 shown.

[0109] It is understood that in other embodiments, the specific implementation of the method flow for evaluating the health status of a sub-user described in 801-810 is not limited to Figure 6 The software structures shown can be implemented in other ways, for example, by using neural network deep learning to train a sub-user health status assessment model, etc., which is not limited here.

[0110] Next, combine Figure 9-10 This article details the software structure involved in managing device-level class keys and the management methods of device-level class keys.

[0111] Figure 9 FIG1 shows a block diagram of the software structure for managing device-level class keys in the mobile phone 100. Figure 9 As shown, the software structure related to managing device-level class keys includes but is not limited to the above-mentioned sub-user status management module 1300, the device-level class key management module 1420, and the kernel file system 1500. Among them, the sub-user status management module 1300 includes but is not limited to the above-mentioned sub-user health status management module 1310 and the current screen working status management module 1320. The functions of the sub-user status management module 1300 and the kernel file system 1500 refer to the above-mentioned Figure 6 The device-level class key management module 1420 includes but is not limited to:

[0112] The device-level class key call policy management module 1421 is used to store, update, and manage the device-level class key call policy. The device-level class key call policy refers to the method or judgment condition used to calculate the load / discard device-level class key instruction. Figure 6 The relevant description of the key management module 1400 will not be repeated here.

[0113] The device-level class key call instruction calculation module 1422 takes the sub-user health status and current screen working status updated by the sub-user status management module 1300 as input, and triggers the acquisition of the device-level class key call policy from the device-level class key call policy management module 1421, and then calculates the device-level class key loading / discarding instruction, and sends the obtained instruction to the device-level class key loading / discarding module 1423.

[0114] The device-level class key loading / discarding module 1423 is used to receive and execute the device-level class key loading / discarding instruction, triggering the kernel file system 1500 to load or discard the device-level class key according to the device-level class key loading / discarding instruction executed by it.

[0115] Figure 10 A schematic diagram of a device-level class key management method is shown. Figure 10 As shown, the process includes the following steps.

[0116] 1001: Obtaining the sub-user health status and current screen working status. Specifically, the processor of the mobile phone 100 runs the corresponding program to execute the function of the device-level class key call instruction calculation module 1422 to obtain the sub-user health status and current screen working status updated by the sub-user status management module 1300.

[0117] 1002: Obtaining the device-level class key invocation policy. Specifically, the processor of the mobile phone 100 runs the corresponding program to execute the functions of the device-level class key invocation instruction calculation module 1422. After obtaining the sub-user health status and current screen working status updated by the sub-user status management module 1300, it triggers the acquisition of the device-level class key invocation policy from the device-level class key invocation policy management module 1421.

[0118] 1003: Based on the acquired sub-user health status and current screen operating state, as well as the device-level class key call policy, a device-level class key load / discard instruction is calculated and generated. Specifically, the processor of mobile phone 100 executes the corresponding program to execute the functions of device-level class key call instruction calculation module 1422. The module uses the sub-user health status and current screen operating state updated by sub-user status management module 1300 as input, triggers the acquisition of the device-level class key call policy from device-level class key call policy management module 1421, and then calculates and sends the device-level class key load / discard instruction to device-level class key load / discard module 1423.

[0119] 1004: Execute the device-level class key load / discard instruction to load / discard the device-level class key in kernel file system 1500. If the device-level class key load instruction is executed, proceed to 1005; if the device-level class key discard instruction is executed, proceed to 1006. Specifically, the processor of mobile phone 100 runs the corresponding program to execute the functions of device-level class key load / discard module 1423, receives the load / discard instruction sent by device-level class key call instruction calculation module 1422, executes the instruction, and notifies kernel file system 1500 to perform the corresponding device-level class key load / discard operation.

[0120] Step 1005 is the same as step 304, and step 1006 is the same as step 305, which will not be repeated here.

[0121] It can be understood that in the device-level sensitive file protection method described in the above steps 301-305, the health status of each sub-user can be re-evaluated each time the mobile phone 100 is restarted, or the health status of each sub-user evaluated after the last startup or before shutdown can be continued during each startup process after the mobile phone 100 is factory set, or the health status of each sub-user evaluated after the current startup of the mobile phone 100 and after the last startup or before shutdown can be weighted calculated to obtain the comprehensive health status of each sub-user. For example, the weight coefficient of the health status of each sub-user evaluated after the last startup or before shutdown is set to 0.2, and the weight coefficient of the health status of each sub-user evaluated after the current startup is set to 0.8, and the weighted calculation is performed to obtain the comprehensive health status of each sub-user. There is no limitation here.

[0122] Figure 11 FIG. 1 shows a schematic structural diagram of a mobile phone 100 according to an embodiment.

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

[0124] It should be understood that the illustrated structure of the embodiment of the present invention does not constitute a specific limitation on the mobile phone 100. In other embodiments of the present application, the mobile phone 100 may include more or fewer components than shown, or some components may be combined or separated, or arranged differently. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0125] The processor 110 may include one or more processing units, for example, an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU). Different processing units may be independent devices or integrated into one or more processors.

[0126] The controller can generate operation control signals according to the instruction operation code and timing signal to complete the control of instruction fetching and execution.

[0127] Processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in processor 110 is a cache memory. This memory can store instructions or data that have just been used or are being recycled by processor 110. If processor 110 needs to use the same instruction or data again, it can directly access the memory. This avoids duplicate accesses, reduces processor 110 latency, and thus improves system efficiency.

[0128] In some embodiments, the processor 110 may include one or more interfaces. The interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a SIM interface, and / or a USB interface.

[0129] The I2C interface is a bidirectional synchronous serial bus that includes a serial data line (SDA) and a serial clock line (SCL). In some embodiments, the processor 110 may include multiple I2C buses. The processor 110 may be coupled to the touch sensor 180K, charger, flash, camera 193, etc. through different I2C bus interfaces. For example, the processor 110 may be coupled to the touch sensor 180K through the I2C interface, so that the processor 110 and the touch sensor 180K communicate through the I2C bus interface to realize the touch function of the mobile phone 100. For example, unlocking authentication is completed by verifying fingerprint information using the touch function of the mobile phone 100.

[0130] It is understood that the interface connection relationship between the modules illustrated in the embodiment of the present invention is merely an illustrative illustration and does not constitute a structural limitation on the mobile phone 100. In other embodiments of the present application, the mobile phone 100 may also adopt a different interface connection method from the above embodiment, or a combination of multiple interface connection methods.

[0131] The charging management module 140 is configured to receive charging input from a charger. While charging the battery 142, the charging management module 140 can also power the electronic device through the power management module 141. The power management module 141 is configured to connect the battery 142, the charging management module 140, and the processor 110. In other embodiments, the power management module 141 and the charging management module 140 can also be provided in the same device.

[0132] The wireless communication function of the mobile phone 100 can be implemented through the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, the modem processor and the baseband processor.

[0133] Antenna 1 and Antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in mobile phone 100 can be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve antenna utilization. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In other embodiments, the antennas can be used in conjunction with a tuning switch.

[0134] The mobile communication module 150 can provide solutions for wireless communications including 2G / 3G / 4G / 5G applied on the mobile phone 100. The mobile communication module 150 may include at least one filter, a switch, a power amplifier, a low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves from the antenna 1, and filter, amplify and process the received electromagnetic waves, and transmit them to the modulation and demodulation processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modulation and demodulation processor, and convert it into electromagnetic waves for radiation through the antenna 1. In some embodiments, at least some of the functional modules of the mobile communication module 150 can be set in the processor 110. In some embodiments, at least some of the functional modules of the mobile communication module 150 can be set in the same device as at least some of the modules of the processor 110.

[0135] The wireless communication module 160 can provide wireless communication solutions including wireless local area networks (WLAN) applied on the mobile phone 100. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, frequency modulates and filters the electromagnetic wave signals, and sends the processed signals to the processor 110. The wireless communication module 160 can also receive signals to be sent from the processor 110, frequency modulate them, amplify them, and convert them into electromagnetic waves for radiation through the antenna 2. In some embodiments, the antenna 1 of the mobile phone 100 is coupled to the mobile communication module 150, and the antenna 2 is coupled to the wireless communication module 160, so that the mobile phone 100 can communicate with the network and other devices through wireless communication technology.

[0136] Mobile phone 100 implements display functions through a GPU, display screen 194, and an application processor. The GPU is a microprocessor for image processing that connects display screen 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 modify display information.

[0137] Display screen 194 is used to display images, videos, and the like. Display screen 194 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a MiniLED, a MicroLED, a Micro-oLed, or a quantum dot light-emitting diode (QLED). In some embodiments, mobile phone 100 may include one or N display screens 194, where N is a positive integer greater than one.

[0138] The SIM card interface 195 is used to connect a SIM card. The SIM card can be connected to and disconnected from the mobile phone 100 by inserting it into or removing it from the SIM card interface 195. The mobile phone 100 can support 1 or N SIM card interfaces, where N is a positive integer greater than 1. The SIM card interface 195 can support Nano SIM cards, Micro SIM cards, SIM cards, and the like. Multiple cards can be inserted into the same SIM card interface 195 at the same time. The types of the multiple cards can be the same or different. The SIM card interface 195 can also be compatible with different types of SIM cards. The SIM card interface 195 can also be compatible with external memory cards. The mobile phone 100 interacts with the network through the SIM card to implement functions such as calls and data communications. In some embodiments, the mobile phone 100 uses an eSIM, i.e., an embedded SIM card. The eSIM card can be embedded in the mobile phone 100 and cannot be separated from the mobile phone 100.

[0139] The software system of the mobile phone 100 can adopt a layered architecture, an event-driven architecture, a micro-kernel architecture, a micro-service architecture, or a cloud architecture. In the embodiment of the present invention, the Android system with a layered architecture is used as an example to illustrate the software structure of the mobile phone 100.

[0140] Figure 12 It is a software structure block diagram of the mobile phone 100 according to an embodiment of the present invention.

[0141] A layered architecture divides software into several layers, each with distinct roles and responsibilities. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers: the application layer, the application framework layer, the Android runtime and system libraries, and the kernel layer.

[0142] The application layer can include a series of application packages.

[0143] like Figure 12 As shown, the application package may include camera, gallery, calendar, call, map, navigation, lock screen, unlock, music, video, short message and other applications.

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

[0145] like Figure 12 As shown, 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.

[0146] The window manager is used to manage window programs. The window manager can obtain the display size, determine whether there is a status bar, lock the screen (i.e., lock the screen), unlock the screen, take screenshots, etc.

[0147] Content providers are used to store and retrieve data and make it accessible to applications. The data may include videos, images, audio, calls made and received, browsing history and bookmarks, phone books, etc.

[0148] The view system includes visual controls, such as those for displaying text and images. The view system is used to build applications. A display interface can consist of one or more views. For example, a display interface containing a text notification icon might include a view for displaying text and a view for displaying images.

[0149] The phone manager is used to provide communication functions of the mobile phone 100, such as management of call status (including answering, hanging up, etc.).

[0150] The resource manager provides various resources for the application, such as authentication data for verifying user information during the unlocking process, localized strings, icons, images, layout files, video files, and so on.

[0151] The notification manager allows applications to display notification information in the status bar. It can be used to convey notification-type messages and can disappear automatically after a short stay without user interaction. For example, the notification manager is used to notify download completion, message reminders, etc. The notification manager can also be a notification that appears in the system top status bar in the form of an icon or scroll bar text, such as notifications of applications running in the background, or a notification that appears on the screen in the form of a dialog window. For example, the above Figure 8The unlocking failure prompt message shown can also be supplemented with notification methods such as prompt sound, electronic device vibration, and indicator light flashing.

[0152] Android Runtime includes core libraries and a virtual machine. Android runtime is responsible for scheduling and management of the Android system.

[0153] The core library consists of two parts: one is the function that needs to be called by the Java language, and the other is the Android core library.

[0154] The application layer and application framework layer run in a virtual machine. The virtual machine executes Java files in the application layer and application framework layer as binary files. The virtual machine manages object lifecycles, stack management, thread management, security and exception management, and garbage collection.

[0155] The system library can include multiple functional modules. For example: surface manager, media library, 3D graphics processing library (for example: OpenGL ES), 2D graphics engine (for example: SGL), and the above Figure 6 and Figure 10 As can be understood, the software modules shown above Figure 6 and Figure 10 The software modules shown may also be provided at the application framework layer, which is not limited here.

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

[0157] The media library supports playback and recording of a variety of common audio and video formats, as well as static image files. The media library can support a variety of audio and video encoding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.

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

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

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

[0161] The following is an example of the workflow of the software and hardware of the mobile phone 100, combined with the lock screen / unlock scenario.

[0162] When the button 190 receives a lock screen / unlock operation, or the touch sensor 180K receives a touch lock screen / unlock operation, it triggers the opening of the lock screen / unlock application located in the application layer. After the lock screen / unlock application is started, the lock screen / unlock notification is sent to the application framework layer, the system library, and the kernel layer layer by layer. The corresponding hardware operation notification is sent to the kernel layer, and the kernel layer processes the lock screen / unlock operation into the original input event (including the lock screen / unlock event and the corresponding timestamp and other information). The original input event is stored in the kernel layer. The application framework layer or the system library obtains the original input event from the kernel layer and identifies the control corresponding to the input event. The device-level sensitive file encryption protection method described in the above steps 301-305 is also controlled and implemented by the processor 110 of the mobile phone 100 in the application framework layer or the system library.

[0163] References in the specification to "one embodiment" or "an embodiment" mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one exemplary implementation or technique disclosed herein. The appearances of the phrase "in one embodiment" in various places in the specification are not necessarily all referring to the same embodiment.

[0164] The present disclosure also relates to a device for performing the operations in the text. The device can be constructed specifically for the required purpose or it can include a general-purpose computer that is selectively activated or reconfigured by a computer program stored in the computer. Such a computer program can be stored in a computer-readable medium, such as, but not limited to, any type of disk, including a floppy disk, an optical disk, a CD-ROM, a magneto-optical disk, a read-only memory (ROM), a random access memory (RAM), an EPROM, an EEPROM, a magnetic or optical card, an application-specific integrated circuit (ASIC), or any type of medium suitable for storing electronic instructions, and each can be coupled to a computer system bus. In addition, the computer mentioned in the specification can include a single processor or can be an architecture involving multiple processors for increased computing power.

[0165] The process and display proposed herein do not inherently relate to any specific computer or other device. Various general-purpose systems can also be used together with the program according to the teachings herein, or it can be convenient to construct more special-purpose devices to perform one or more method steps. The structure for various these systems is discussed in the following description. In addition, any specific programming language that is enough to realize the technology and embodiment disclosed in the present application can be used. Various programming languages ​​can be used to implement the present disclosure, as discussed herein.

[0166] Additionally, the language used in this specification has been primarily selected for readability and instructional purposes and may not have been selected to delineate or circumscribe the disclosed subject matter.Thus, this disclosure is intended to illustrate but not to limit the scope of the concepts discussed herein.

Claims

1. A device-level sensitive file protection method, applied to an electronic device, wherein multiple sub-users are logged in to the electronic device, characterized in that: The method comprises: Evaluate the health status of the multiple sub-users and obtain the screen working status of the electronic device; wherein the health status is at least used to describe the safety level of the sub-users; Obtaining a device-level class key invocation policy to determine the type of device-level class key to be invoked, wherein the device-level class key is used to access a device-level sensitive file, and the device-level class key is a key used to encrypt or decrypt a file key of the device-level sensitive file, and the device-level class key invocation policy is a policy that is set or updated based on a user's operating habits of switching sub-user logins and is used to manage the loading or discarding of the device-level class key; Determining whether to load the device-level class key or discard the device-level class key based on the health status of the multiple sub-users, the screen working status of the electronic device, and the device-level class key calling policy; The loading of the device-level class key includes copying the device-level class key to a kernel file system of the electronic device; and the discarding of the device-level class key includes deleting the device-level class key from the kernel file system of the electronic device.

2. The method according to claim 1, characterized in that Determining, based on the health status of the multiple sub-users, the screen working status of the electronic device, and the device-level class key calling policy, to load the device-level class key or discard the device-level class key includes: Determining to load the device-level class key if the health status of the multiple sub-users and the screen working status of the electronic device meet the device-level class key loading policy in the device-level class key calling policy; In a case where the health status of the multiple sub-users and the screen working status of the electronic device do not comply with the device-level class key loading policy, it is determined to discard the device-level class key.

3. The method according to claim 2, characterized in that The health status is also used to describe the activity level of the sub-user; The device-level class keys include a first device-level class key, a second device-level class key, and a third device-level class key; The screen working state includes a locked state or an unlocked state, wherein the unlocked state includes an unlocked success state in which unlock authentication is successfully completed after an unlock event is triggered, and an unlocked failure state in which the unlock authentication is not successfully completed.

4. The method according to claim 3, characterized in that The device-level class key loading strategy includes one of the following: After any healthy sub-user among the multiple sub-users logs in on the electronic device, if the first unlock state of the electronic device is the unlock success state, loading the first device-level class key; When the first unlocking state after any healthy sub-user is logged in on the electronic device is the unlocking success state, and the first unlocking state after the first sub-user is currently logged in on the electronic device is the unlocking success state, loading the first device-level class key; When a first healthy sub-user among the multiple sub-users is currently logged in on the electronic device and a current screen working state of the electronic device is the unlocked successful state, loading the second device-level class key or the third device-level class key; When the unlock state after logging in any health sub-user on the electronic device includes at least one of the unlock success states, and the current unlock state of the first health sub-user logged in on the electronic device is the unlock success state, loading the second device-level class key or the third device-level class key; The multiple sub-users include any one of the health sub-users, the first health sub-user, and the first sub-user.

5. The method according to claim 4, characterized in that The evaluating the health status of the plurality of sub-users includes: Obtaining a health status parameter of a first sub-user among the plurality of sub-users, wherein the health status parameter is used at least to calculate the activity level and safety level of the sub-user; and When the health status parameter of the first sub-user meets a preset threshold condition, the sub-user is evaluated as a healthy sub-user.

6. The method according to claim 5, characterized in that The health status parameters include the sub-user creation time of the first sub-user, the total number of unlock attempts, the number of unlock failures or the number of unlock successes when logging in to the first sub-user on the electronic device, and the total unlock active time; wherein, The total number of unlock attempts is the number of times the unlock event is triggered, the number of unlock failures is the number of times the unlock failure state occurs, and the number of unlock successes is the number of times the unlock success state occurs.

7. The method according to claim 6, characterized in that The evaluating the health status of the plurality of sub-users further includes: If the ratio of the total unlocking active time to the first sub-user creation time is greater than or equal to a preset activity threshold, determining the activity level of the first sub-user to be active; When the total number of unlock attempts is greater than or equal to the preset number threshold, and If the ratio of the number of unlock failures to the total number of unlock attempts is less than or equal to a preset risk rate threshold, determining that the security level of the first sub-user is safe; or If the ratio of the number of successful unlocking attempts to the total number of unlocking attempts is greater than or equal to a preset success rate threshold, determining that the security level of the first sub-user is safe; When the first sub-user is active and safe, the first sub-user is determined to be a healthy sub-user.

8. The method according to any one of claims 1 to 7, characterized in that: The first device-level class key is the device-level credential encryption class key, the second device-level class key is the device-level enhanced encryption class key, and the third device-level class key is the device-level comprehensive encryption class key.

9. A computer-readable storage medium, characterized in that The storage medium stores instructions, which, when executed on a computer, enable the computer to execute the device-level sensitive file protection method according to any one of claims 1 to 7.

10. An electronic device, characterized in that: comprising one or more processors; one or more memories; wherein, The one or more memories store one or more programs, and when the one or more programs are executed by the one or more processors, the electronic device executes the device-level sensitive file protection method according to any one of claims 1 to 7.

Images