CN114722419A

CN114722419A - Equipment-level sensitive file protection method, storage medium and electronic equipment

Info

Publication number: CN114722419A
Application number: CN202110004092.0A
Authority: CN
Inventors: 陆琦玮; 靳亮
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2021-01-04
Filing date: 2021-01-04
Publication date: 2022-07-08

Abstract

The application relates to the technical field of file-level encryption, in particular to a device-level sensitive file protection method, a storage medium and an electronic device. The method is applied to the electronic equipment, a plurality of sub-users log in the electronic equipment, and the method comprises the following steps: evaluating the health states of a plurality of sub-users and acquiring the screen working state of the electronic equipment; obtaining a device-level class key calling strategy to determine the type of calling the device-level class key; and determining to load the device-level class key or discard the device-level class key based on the health states of the plurality of sub-users, the screen working state of the electronic device and the device-level class key calling policy. According to the method and the device, the device-level sensitive files are protected by adopting the device-level keys, whether the device-level keys are loaded to access the device-level sensitive files is determined based on the health state of each sub-user and the working state of the current device screen, and therefore safe and barrier-free access of each sub-user to the device-level sensitive files is achieved, namely safe sharing of the device-level sensitive files is achieved.

Description

Equipment-level sensitive file protection method, storage medium and electronic equipment

Technical Field

The invention relates to the technical field of File-Based Encryption (FBE), in particular to a device-level sensitive File protection method, a storage medium and an electronic device.

Background

In the field of sensitive file protection in a terminal file system, in order to prevent a mobile phone and other terminal electronic devices from physical attacks under a non-user-authorized condition after being lost, for example, the terminal file system is forcibly accessed through a USB to obtain the content of the device, which causes leakage of important private data files (hereinafter referred to as sensitive files) of a user, an FBE technology is generally used in the prior art to perform file-level protection on the sensitive files in the terminal file system. In the terminal operation system, the encryption types of the sensitive files with different sensitivity degrees in the terminal file system are set to be different. For example, as shown in fig. 1, in an android operating system, encryption types corresponding to sensitive files with different sensitivity degrees in a terminal file system 1000 mainly include two major types, namely a device-level encryption type and a user-level encryption type, and specifically include the following four types: a Device-level Non-Encrypted (Global NE, such as an Over-the-Air (OTA) upgrade package) class, a Device-level Device Encrypted (DE) class, a user-level DE class, and a user-level Credential Encrypted (CE) class. In the Huaji terminal operating system based on the android operating system, two types of encryption types of sensitive files are added, namely a Sub-Enhanced confidential Encrypted (SECE) type and a user-level Enhanced Confidential Encrypted (ECE) type which are supplemented by users. The sensitive file protected by the device-level encryption type can be accessed by different users on the same terminal, and the sensitive file only supports the access of the users.

Because the sensitive file protected by the user-level encryption type only supports the access of the user, if a user logs in a plurality of sub-users on a certain terminal based on the use requirement, for example, the user needs to create or switch to a pure sub-user desktop to be used as the personal learning space of the user for login, if the sub-user needs to access the sensitive file protected by the user-level SECE/ECE class established when other sub-users log in, the sub-user cannot break through the limitation problem that the user-level encryption type is only bound with a single sub-user, and cannot access the sensitive file, so that the user experience is poor.

Disclosure of Invention

The embodiment of the application provides a device-level sensitive file protection method, a storage medium and electronic equipment, wherein a device-level key is adopted for carrying out secondary encryption protection on a file key of a device-level sensitive file, whether the device-level key is loaded or not is determined based on the evaluation of the health state of each sub-user and the working state of a current device screen, so as to determine whether the device-level sensitive file can be accessed and used, the safe and barrier-free access of each sub-user to the device-level sensitive file is realized, and the limitation problem that the sensitive file protected by the current user-level encryption type is only bound with a single sub-user is broken through.

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 a plurality of sub-users log in the electronic device, and the method includes: evaluating the health states of the sub-users and acquiring the screen working state of the electronic equipment; wherein the health status is at least used to describe a safety level of the sub-user; obtaining a device-level class key calling strategy to determine the type of calling the device-level class key, wherein the device-level class key is used for accessing the device-level sensitive file; determining to load the device-level class key or discard the device-level class key based on the health states of the plurality of sub-users, the screen working state of the electronic device, and the device-level class key calling policy; wherein said loading said device level class key comprises copying said device level class key to a kernel file system of said electronic device; discarding the device-level class key may include deleting the device-level class key from a kernel file system of the electronic device.

That is, the health status of a plurality of sub-users and the screen working status of the electronic screen meet the condition of safely accessing the device-level sensitive file, and each sub-user can access the device-level sensitive file, wherein the device-level sensitive file is a file type shared among the sub-users which can log in on the electronic device.

For example, the device-level sensitive file may be a screenshot saved when each sub-user logs in, a shot photo, a recorded audio file, and the like. The files in the electronic device are set as device-level sensitive files, and can be determined or set according to the use requirements or use habits of users.

In a possible implementation of the first aspect, determining to load the device-level class key or discard the device-level class key based on the health statuses of the plurality of sub-users, the screen operating status of the electronic device, and the device-level class key invoking policy includes: determining to load the device-level key under the condition that the health states of the sub-users and the screen working state of the electronic device conform to a device-level key loading policy in the device-level key calling policy; and determining to discard the device-level class key under the condition that the health states of the plurality of sub-users and the screen working state of the electronic device do not accord with the device-level class key loading strategy.

Namely, the device-level sensitive file calling strategy comprises a device-level sensitive file loading strategy and a device-level sensitive file discarding strategy, and when the health state of the sub-user and the screen working state of the electronic device meet the device-level sensitive file loading strategy, the device-level key is determined to be copied and loaded. The condition that the device-level sensitive file loading policy is not satisfied belongs to the condition that the device-level sensitive file discarding policy is satisfied. And under the condition that the health state of the sub-user and the screen working state of the electronic equipment do not meet the loading strategy of the equipment-level sensitive file, namely the condition that the equipment-level sensitive file is discarded is met, and under the condition, the loaded equipment-level key is determined to be discarded and deleted.

For example, a device-level sensitive file that a sub-user who logs in on the current electronic device needs to access to use is a screenshot saved by another sub-user when logging in, and after loading a device-level key of such a device-level sensitive file, the file key used for encrypting the screenshot file can be decrypted and used, so that the screenshot file can be decrypted, and the sub-user who logs in on the current electronic device can access to use the screenshot file. If the device-level class key of a device-level sensitive file such as the screenshot file is discarded, the file key used to decrypt the screenshot file is not available, and accordingly, the screenshot file protected by file key encryption is not accessible for use.

In a possible implementation of the first aspect, the method further includes: the health status is also used for describing the activity level of the sub-user; the device-level class key comprises a first device-level class key, a second device-level class key and a third device-level class key; the screen working state comprises a screen locking state or an unlocking state, wherein the unlocking state comprises an unlocking success state in which unlocking authentication is successfully completed after an unlocking event is triggered and an unlocking failure state in which the unlocking authentication is not successfully completed.

Namely, the health status of each sub-user is used for describing the activity level and the safety level of each sub-user, and when the activity level and the safety level of the sub-user meet the health requirement, the health status of the sub-user can be evaluated as healthy. It is to be understood that the health status of each sub-user may also be used to describe other status characteristics of the sub-user, such as the confidence level of each sub-user, and the like, and is not limited to the above-mentioned activity level and security level, and is not limited herein.

The device-level class key may be correspondingly divided into multiple classes of keys according to the sensitivity degree or sensitivity level of the device-level sensitive file protected by the device-level class key, and it can be understood that the device-level class key is not limited to the first device-level class key, the second device-level class key, and the third device-level class key, and may also include more classes, which is not limited herein.

The screen working state of the electronic device may include, but is not limited to, a screen locking state or an unlocking state in a current sub-user login state, the screen locking in the screen locking state is inoperable, the unlocking state may further include an unlocking failure state in which unlocking authentication fails and an unlocking success state in which unlocking authentication succeeds, the screen in the unlocking failure state is still in the screen locking state and may automatically enter the screen locking state when no operation is performed for a period of time, and the screen in the unlocking success state may work, for example, the screen is clicked to start an application program and the like. The screen working state of the electronic device may further include that when the current sub-user is switched to another sub-user for logging in, the electronic device should be in an unlocking success state in the logging-in state of the other sub-user without repeated unlocking authentication, if the logging-in is switched and the unlocking authentication is required, the electronic device should be in the unlocking success state in the logging-in state of the other sub-user is updated when the unlocking authentication is successful, and the electronic device should be in the unlocking failure state in the logging-in state of the other sub-user is updated when the unlocking authentication is failed. The screen operating state of the electronic device is not limited to the screen locking state and the screen unlocking state in the above-described various situations, and is not limited herein.

In a possible implementation of the first aspect, the device-level class key loading policy includes one of: loading the first device-level class key when the first unlocking state of the electronic device is the unlocking success state after any healthy sub-user in the plurality of sub-users logs in the electronic device; loading the first device-level key under the condition that the first unlocking state after any healthy sub-user logs in on the electronic device is the unlocking success state and the first unlocking state after the first sub-user logs in on the electronic device is the unlocking success state; loading the second device-level key or the third device-level key when a first healthy sub-user of the plurality of sub-users logs in the electronic device currently and the current screen working state of the electronic device is the unlocking success state; the unlocking state after any healthy sub-user logs in on the electronic equipment at least comprises the unlocking success state once, and the second equipment-level key or the third equipment-level key is loaded under the condition that the current unlocking state of the first healthy sub-user currently logged in on the electronic equipment is the unlocking success state; wherein the plurality of sub-users includes the any healthy sub-user, the first healthy sub-user, and the first sub-user.

The loading or discarding of the first device-level key is closely related to the first unlocking success of the electronic device after whether a healthy sub-user logs in and whether the sub-user currently logging in the electronic device successfully unlocks for the first time; the loading or discarding of the second equipment-level key or the third equipment-level key is closely related to whether a healthy sub-user logs in the electronic equipment or not and whether the current electronic equipment is in an unlocking success state or not; or the loading or discarding of the second device-level key or the third device-level key is closely related to whether the healthy sub-user logs in the electronic device to be in the unlocking success state or not, and whether the device is in the unlocking success state or not when the healthy sub-user logs in the electronic device at present.

It is to be understood that the device-level class key loading policy in the device-level class key invoking policy is not limited to the above-mentioned cases, but may also include other cases where it is determined to load the device-level class key, and is not limited herein.

For example, the device-level sensitive file to be protected by the first device-level key is the screenshot stored in the screenshot, and when the healthy sub-user logs in the electronic device and then unlocks the electronic device successfully for the first time, the first device-level key may be loaded for accessing and using the screenshot.

In a possible implementation of the first aspect, the evaluating the health status of the plurality of sub-users includes: acquiring a health state parameter of a first sub-user of the plurality of sub-users, wherein the health state parameter is at least used for calculating the activity degree and the safety degree of the sub-user; and under the condition that the health state parameter of the first sub-user meets a preset threshold value condition, evaluating that the sub-user is a healthy sub-user.

The health state parameters comprise the creation time of the sub-user of the first sub-user, the total unlocking attempt times, the unlocking failure times or the unlocking success times and the total active unlocking time when the electronic equipment logs in the first sub-user; the total attempted unlocking times are times of triggering an unlocking event, the unlocking failure times are times of occurrence of the unlocking failure state, and the unlocking success times are times of occurrence of the unlocking success state.

Namely, the activity degree and the safety degree of the sub-user are calculated through the health state parameters, and then the health state of the sub-user is evaluated. It is to be understood that the health status parameters are not limited to the above sub-user creation time, total number of attempts to unlock, number of failed unlocking times or successful unlocking times, and total unlocking active time, and may also include other characteristics that may be used to calculate activity level, security level, or other status features, and are not limited herein.

For example, the activity level of the sub-user is calculated through the creation time length of the sub-user and the total unlocking activity time length, and the activity level is active or inactive; and calculating the safety degree of the sub-user through the total unlocking attempt times, the unlocking failure times or the unlocking success times, wherein the sub-user is safe or has risks.

In a possible implementation of the first aspect, the evaluating the health statuses of the plurality of sub-users further includes: determining the activity degree of the first sub-user to be active under the condition that the ratio of the total unlocking activity duration to the first sub-user creating duration is greater than or equal to a preset activity threshold value; determining the safety degree of the first sub-user as safe under the condition that the total attempted unlocking times are greater than or equal to a preset time threshold value and the ratio of the unlocking failure times to the total attempted unlocking times is less than or equal to a preset risk rate threshold value; or under the condition that the ratio of the unlocking success times to the total attempted unlocking times is greater than or equal to a preset success rate threshold, determining the safety degree of the first sub-user as safe; determining that the first sub-user is a healthy sub-user if the first sub-user is active and safe.

That is, the health status of each sub-user may be integrated with a plurality of status features, for example, the activity level and safety level of the sub-user to evaluate whether the health status is healthy or unhealthy. It is to be understood that the health status evaluation of each sub-user is not limited to the above-mentioned activity level and safety level, and may also be evaluated by integrating a greater or lesser number of status characteristics or by integrating other status characteristics, which is not limited herein.

In a possible implementation of the 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.

In a second aspect, the present application provides a computer-readable storage medium, on which instructions are stored, and when executed on a computer, the instructions cause the computer to execute the above-mentioned device-level sensitive file protection method.

In a third aspect, an embodiment of the present application provides an electronic device, including one or more processors; one or more memories; wherein the one or more memories store one or more programs that, when executed by the one or more processors, cause the electronic device to perform the above-described device-level sensitive file protection method.

In a fourth aspect, embodiments of the present application provide a computer program product, which includes a computer program/instruction, and when the computer program/instruction is executed by a processor, the method for protecting a device-level sensitive file described above is implemented.

Drawings

Fig. 1 is a schematic view illustrating a terminal file system structure on an electronic device with multiple sub-users according to an embodiment of the present application.

Fig. 2 is a diagram illustrating an exemplary comparison table of encryption types of sensitive files under different operating systems according to an embodiment of the present application.

Fig. 3 is a schematic flowchart illustrating a method for protecting a device-level sensitive file according to an embodiment of the present application.

Fig. 4a is a schematic view illustrating a process interface for creating/logging in a sub-user according to an embodiment of the present application.

Fig. 4b is a schematic diagram illustrating a process interface for creating/logging in a sub-user according to an embodiment of the present application.

Fig. 4c is a schematic view illustrating a process interface for creating/logging in a sub-user according to an embodiment of the present application.

Fig. 4d is a schematic diagram illustrating a process interface for creating/logging in a sub-user according to an embodiment of the present application.

FIG. 5a is a schematic diagram of an interface corresponding to operation (r) in FIG. 4 d.

FIG. 5b is a schematic diagram of an interface corresponding to operation (C) in FIG. 4 d.

Fig. 6 is a schematic block diagram illustrating a structure of relevant software for managing the health status of the sub-user in the mobile phone 100 according to the embodiment of the present application.

Fig. 7 is a schematic diagram illustrating a health status parameter of a sub-user 100-n and a corresponding health status evaluation result according to an embodiment of the present application.

Fig. 8 is a flowchart illustrating a method for evaluating the health status of a sub-user 100-n according to an embodiment of the present disclosure.

Fig. 9 is a block diagram illustrating a related software structure for managing a device-level class key in the handset 100 according to an embodiment of the present application.

Fig. 10 is a flowchart illustrating a method for managing a device-level class key according to an embodiment of the present application.

Fig. 11 is a schematic structural diagram of a mobile phone 100 according to an embodiment of the present disclosure.

Fig. 12 is a block diagram illustrating a software structure of a mobile phone 100 according to an embodiment of the present disclosure.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application clearer, the technical solutions of the embodiments of the present application are described in further detail below by combining the drawings and the embodiments.

Fig. 1 is a schematic diagram of a terminal file system of multiple sub-users according to an embodiment of the present application. As shown in FIG. 1, a user has a plurality of sub-users 100-n on an electronic device 100, including sub-user 100-1 through sub-user 100-n. In the prior art, when a user switches from the sub-user 100-1 to the sub-user 100-2 for logging in, the sub-user 100-2 cannot access device-level sensitive files generated by the user on the sub-user 100-1, such as a shot photo, a stored screenshot, a downloaded document, and the like, which is mainly due to that such sensitive files are still of a user-level encryption type in the prior art, and the user-level encryption type is only bound with a single sub-user, so that there are many inconveniences when the user switches between the sub-users created by the user. The device-level sensitive file can be understood as a sensitive file type which can be shared among sub-users based on the use requirements of the users.

As shown in fig. 1, in the terminal file system of the electronic device 100, the encryption types of the sensitive file protection for different sensitivity levels include: a Non-Encrypted (NE) class 1010, such as an Over The Air (OTA) upgrade package file, is set in The prior art; a Device Encrypted (DE) class 1011, such as a user profile (profile) of an Application (APP); user-level DE class 1021, such as bluetooth paired data, alarm clock, ring tone, etc.; a user-level Credential Encrypted (CE) class 1022, such as downloaded documents, stored screenshots, and the like; a Sub-Enhanced Encrypted (see) class 1023, such as motion data recorded by a motion APP; user-level fully Encrypted (ECE) classes 1024, such as contacts, wallets, account information, and the like; and a device-level CE class 1012, a device-level see class 1013, and a device-level ECE class 1014, as constructed herein. The sensitive files protected by the device-level CE class 1012 and the user-level CE class 1022, the device-level CE class 1013 and the user-level CE class 1023, and the device-level ECE class 1014 and the user-level ECE class 1024 may be the same or different, and may be specifically set based on the use requirement of the user, which is not limited herein.

In order to solve the above technical problem, the present application provides a method for protecting a device-level sensitive file, where the device-level encryption types for protecting the device-level sensitive file are constructed, such as a device-level CE class 1012, a device-level see class 1013, and a device-level ECE class 1014, and the present application performs secondary encryption protection on a file key of the device-level sensitive file by 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 decrypt the file key, so as to access and use the protected device-level sensitive file. Therefore, the method and the device break through the limitation that the user-level encryption type is only bound with a single sub-user, so that the user can access various device-level sensitive files generated when other sub-users log in under the condition that the health state of the sub-user meets the safety requirement, and meanwhile, the method and the device double-protect the device-level sensitive files by using the file key and the device-level key, so that the safety of the device-level sensitive files is improved, the safe barrier-free access of the sub-users to the device-level sensitive files is realized, and the use experience of switching the login among the sub-users by the user is greatly improved.

It is to be appreciated that the electronic device 100 described above may include, but is not limited to, laptop computers, desktop computers, tablet computers, smart speakers, cell phones, wearable devices, large screen display devices such as head-mounted displays, large screen televisions, large screen displays, vehicle-mounted computers, vehicle-mounted smart systems such as vehicle-mounted voice navigation, and smart robots, portable music players, reader devices, and other electronic devices capable of accessing a network in which one or more processors are embedded or coupled. For convenience of description, the electronic device 100 is taken as an example of the mobile phone 100.

It is understood that the operating system of the handset 100 may be an android operating system, an operating system further developed based on android native (e.g., hua shi EMUI system), an iOS operating system, a hong meng operating system, and the like, and is not limited herein. For convenience of description, the operating system of the mobile phone 100 is taken as an android operating system for illustration.

For ease of understanding, the following briefly introduces the concept related to the encryption type of sensitive files in the android operating system.

The DE type is an encryption type of a sensitive file that can be accessed and used after the mobile phone 100 is powered on, and includes operations such as opening, creating, writing and the like of a protected sensitive file without user authentication.

The CE class refers to a sensitive file encryption type in which a key needs to be loaded by a user unlocking authenticator for access and use when the mobile phone 100 is unlocked for the first time after being powered on, and the sensitive file is subsequently accessed and used without user authentication after the mobile phone 100 is unlocked for the first time, that is, after the mobile phone 100 is unlocked for the first time, the sensitive file protected by the CE class can be directly accessed and used in a locked or unlocked state. The user unlocking authentication mode includes but is not limited to a PIN code input mode, a fingerprint verification mode or a face recognition mode.

The SECE class refers to a sensitive file encryption type enhanced on the basis of the CE scheme, that is, a sensitive file encryption type that needs to be authenticated by a user when the mobile phone 100 is turned on and unlocked for the first time and can be accessed and used by loading a secret key under the unlocked state of the mobile phone 100. It can be understood that the sensitive file protected by the SECE class in the screen-locked state of the mobile phone 100 cannot be opened, but can be newly created and written; in the unlocked state of the electronic device 100, the sensitive file protected by the SECE class can be opened, newly created, and written.

The ECE class is a sensitive file encryption type further enhanced on the see scheme, that is, a sensitive file encryption type that needs to be authenticated by a user when the mobile phone 100 is first powered on and can be accessed and used by loading a key only under the unlocked state of the mobile phone 100. It can be understood that the sensitive file protected by the ECE class cannot be opened, newly created, written in, and the like in the screen locking state of the mobile phone 100; only in the unlocked state of the electronic device 100, the sensitive file protected by the ECE class can be opened, newly created, and written.

It is understood that the device-level sensitive file protection method of the present application is also applicable to other operating systems, such as the iOS system of apple, and is not limited thereto. In the iOS system, the sensitive file encryption types include four ABCD types, as shown in fig. 2, for example, by comparing the protection method of the four ABCD types in the iOS system for sensitive files with different degrees with the protection method of the four types in the android operating system for sensitive files with different degrees, the correspondence between the iOS system and the sensitive file encryption types in the android operating system is as follows: class DE corresponds to class D; the CE class corresponds to the C class; the SECE class corresponds to the B class, and the ECE class corresponds to the A class. And will not be described in detail herein.

The device-level sensitive file protection scheme of the present application will be described in detail below with reference to the accompanying drawings and specific embodiments based on the terminal file system shown in fig. 1.

Example one

FIG. 3 shows a schematic flow diagram of the device-level sensitive file protection method of the present application. By way of example, the steps shown in FIG. 3 are implemented in the handset 100, wherein the creation of the sub-user is performed by the processor of the handset 100 by running an application; the steps of evaluating, determining, etc. are performed by the processor of the handset 100 by running the program modules.

As shown in fig. 3, the implementation steps of the device-level sensitive file protection method include:

301: create/log in sub-user 100-n.

Generally, when the mobile phone 100 is used at initial power-on, a device account needs to be bound, and the binding information on the device account generally includes, but is not limited to, a mobile phone number, a wallet account, and the like corresponding to a SIM card installed in the mobile phone 100. In addition, under the setting interface of the mobile phone 100, a plurality of sub-users can be created and logged in, wherein each sub-user has an independent desktop setting, and the sub-users can install the same or different application programs of other sub-users and set the same or different unlocking passwords during logging in. It should be noted that, in the case that the bound device account is not replaced or logged out, a plurality of sub-users logged in 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 handset 100 may be illustrated with reference to fig. 4a-4 d.

Fig. 4a-4d show schematic diagrams of a process interface for creating/logging in a sub-user on the handset 100. As shown in fig. 4a, during the use of the mobile phone 100, a user needs to use another clean desktop at a certain time or within a certain period of time to meet the use requirement, for example, the user needs a clean desktop without various games, entertainment, chatting, or payment applications to install a learning application for non-interference learning, or needs a clean desktop to provide a non-interference desktop environment for children to learn a web lesson. As shown in fig. 4a-4d, when a user needs to create a sub-user or switch to log in to another sub-user desktop, the user may enter the setting interface shown in fig. 4b by clicking the setting application on the desktop of the mobile phone 100, the user continues to click "user and account", enter the user and account interface shown in fig. 4c, the user continues to click "multi-user", and enters the multi-user interface shown in fig. 4d, in the multi-user interface shown in fig. 4c, the user may click "add user" to perform operation (i), or click "sub-user 100-2" or "sub-user 100-3" to perform operation (ii).

After operation, the operation frame shown in fig. 5a is popped up from the mobile phone 100, the relevant function introduction of the new user can be known in the operation frame, the user-defined name of the sub-user to be created can be input at the nickname, after the input is completed, the sub-user can be created by clicking add, the relevant information of the new sub-user and the basic settings such as the network can be started, and the sub-user can be cancelled by clicking cancel, and the interface shown in fig. 4d is returned. It can be understood that the process of creating the sub-user can complete the login of the newly created sub-user, that is, the mobile phone 100 has switched to the new sub-user desktop when the new sub-user creation is completed.

Operation II is the operation of switching login sub-users, after operation II is performed, the mobile phone 100 pops up a confirmation frame shown in fig. 5b, and asks the user to confirm whether to switch to a new user, the user can switch to the selected sub-user login by clicking the confirmation frame, and the user can cancel the operation of switching login sub-users and return to the interface shown in fig. 4d by clicking the cancellation frame.

It is to be understood that the 3 sub-users shown in fig. 4d (i.e., sub-user 100-1, sub-user 100-2, and sub-user 100-3) do not constitute a limitation on the number of sub-users, and in other implementations, the user may create any number of sub-users on the mobile phone 100, and is not limited herein. In other embodiments, the sub-user 100-1 in fig. 4d may also be displayed as an "owner," which has the authority of a device administrator, may manage the creation or deletion of other sub-users (e.g., the sub-user 100-2, the sub-user 100-3), and the names and the authorities of other sub-users (e.g., the sub-user 100-2, the sub-user 100-3) may be customized based on the user preference or the usage habit, which is not limited herein.

302: the health status of the sub-user 100-n is evaluated and updated, as well as the screen work status of the mobile phone 100 when the current sub-user logs in. The processor of the mobile phone 100 determines health attribute characteristics such as the activity level and the security level of each sub-user 100-n by triggering the data related to the screen locking/unlocking event in the login state of each sub-user, and evaluates the health state of each sub-user based on the health attribute characteristics.

It can be understood that the screen operating states of the mobile phone 100 include a screen inoperable state after locking a screen when logging in a certain sub-user, a screen inoperable state after an unlocking failure, a screen operable state after an unlocking success, and a screen inoperable state after an unlocking failure or a screen operable state after an unlocking success, which may occur after re-unlocking authentication when switching to another sub-user logging in the screen operable state after an unlocking success, and the like.

For example, the activity level of the corresponding sub-user can be determined by the creation time length and the total unlocking activity time length of the sub-user, the security level of the corresponding sub-user can be determined by the updated total unlocking attempt times and the updated unlocking failure times of the sub-user in the login state of the sub-user, and the like. The software structure involved in the evaluation of the health status of the sub-user 100-n and the evaluation method of the health status of the sub-user will be described in detail below, and will not be described herein again.

303: based on the health status of each sub-user, the current screen operating status of the mobile phone 100, and the obtained device-level key calling policy, it is determined whether to load or discard the device-level key in the kernel file system of the mobile phone 100. The device-level key invoking policy includes a loading policy and a discarding policy, and it can be understood that the case that the processor of the mobile phone 100 determines that the case does not conform to the device-level key loading policy, that is, the case that the case conforms to the device-level key discarding policy. When the health status of each sub-user and the screen working status of the current mobile phone 100 conform to the loading policy in the device-level key calling policy, the processor of the mobile phone 100 determines to load the device-level key, and proceeds to 304; when the health status of each sub-user and the current screen operating status of the mobile phone 100 conform to the discarding policy in the device-level class key invoking policy, the processor of the mobile phone 100 determines to discard the device-level class key, and proceeds to 305.

It can be understood that the device-level key invoking policy may be set, and the policy may also be updated or updated based on the operation usage habit of the user to switch the sub-user login, where the device-level key invoking policies of different encryption types are different; the health status of each sub-user and the current screen operating status of the mobile phone 100 are the implementation results of the above step 302. The software structure involved in managing the device-level class keys and the management method of the device-level class keys will be described in detail below, and will not be described in detail herein.

304: and loading the device-level class key, decrypting to obtain a file key, and making the device-level sensitive file accessible for use. If the judgment result of the step 303 or the obtained execution instruction is to load the device-level key, the processor of the mobile phone 100 controls the storage path accessing the device-level key, and loads the device-level key into the kernel file system to decrypt the file key, where the decrypted file key is used to decrypt the protected device-level sensitive file data.

It can be understood that after the protected device-level sensitive file is decrypted, the sub-user currently logged in on the mobile phone 100 may access the device-level sensitive file data generated when other sub-users log in, for example, after the device-level class key is loaded for decryption, the sub-user 100-2 currently logged in may access the screenshot (device-level CE class), the historical motion data (device-level SECE class), or the stored contact (device-level ECE class) stored when the sub-user 100-logs in.

305: and discarding the device-level class key, making the file key unavailable, and making the device-level sensitive file inaccessible for use. If the judgment result of the step 303 or the obtained execution instruction is to discard the device-level class key, the processor of the mobile phone 100 controls to delete the loaded device-level class key from the kernel file system.

It can be understood that after the device-level class key is deleted, the corresponding file key is also deleted, so that the currently registered sub-user cannot access the device-level sensitive file data generated when other sub-users log in. For example, after the kernel file system of the mobile phone 100 discards the device-level class key for decryption, the currently logged-in sub-user 100-2 cannot access the device-level CE class sensitive file created by using other sub-users, such as the screenshot stored during the logging-in of the sub-user 100; the currently logged-in sub-user 100-2 also cannot access device-level SECE classes created using other sub-users, such as historical athletic data; or device-level ECE class sensitive files created under other sub-users, such as stored contacts, etc.

The software structure involved in assessing the health status of the sub-user 100-n and the method of assessing the health status of the sub-user will be described in detail below with reference to fig. 6-9.

Fig. 6 shows a schematic block diagram of the relevant software structure for managing the health status of the sub-users in the handset 100. As shown in fig. 6, the related software structures for managing the health status of the sub-users include, but are 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; class key management module 1400 includes, but is not limited to, a user-level class key management module 1410, a device-level class key management module 1420.

Specifically, the user management module 1100 is configured to perform management operations such as creation, switching login, and deletion of a sub-user, the user management module 1100 is further configured to perform password modification of a lock screen/unlock password, fingerprint information, face identification information, and the like by the sub-user, and to verify the password of the lock screen/unlock password, fingerprint information, face identification information, and the like, and the user management module 1100 is further configured to record and update data such as user creation time length. The creating, switching and logging-in processes of the sub-user may refer to fig. 4a to 4d, fig. 5a to 5b and related descriptions, which are not described herein again.

The screen locking/unlocking module 1200 is configured to obtain various trigger events on the mobile phone 100, determine whether the type of the obtained trigger event is a screen locking event or an unlocking event, and when the trigger event is an unlocking event, the screen locking/unlocking module 1200 is further configured to determine whether the unlocking event is successful, and send the screen locking/unlocking related data to the sub-user state management module 1300. It is to be understood that when the trigger event is not a lock/unlock event, the lock/unlock module 1200 does not process the trigger event.

The sub-user state management module 1300 is configured to perform management operations such as evaluation and update on the state attributes of the sub-user, wherein the sub-user health state management module 1310 is configured to perform management operations such as evaluation and update on the health state of the user, and the current screen working state management module 1320 is configured to perform management operations such as real-time update on the current screen working state of the mobile phone 100. It is understood that when the screen operating status of the mobile phone 100 is updated, the screen locking/unlocking related data, such as the total active unlocking duration, the total attempted unlocking times, the number of failed unlocking times or the number of successful unlocking times of the sub-user 100-n, may be synchronously updated to the sub-user health status management module 1310 for the module to evaluate and update the health status of the sub-user. The sub-user health status management module 1310 may evaluate the health status of the sub-users 100-n with reference to the following example.

FIG. 7 shows a schematic diagram of the health status parameters of the sub-user 100-n and the corresponding health status assessment results. As shown in fig. 7, after the screen locking/unlocking module 1200 determines that the trigger event is a screen locking/unlocking event, the corresponding screen locking/unlocking data is synchronously updated to the sub-user state management module 1300, the sub-user health state management module 1310 in the sub-user state management module 1300 obtains the corresponding screen locking/unlocking data, updates the health state parameter of the sub-user 100-n, and evaluates the health state of the sub-user 100-n, and the current screen working state management module 1320 obtains the corresponding screen locking/unlocking data, and updates the current screen working state of the updated sub-user 100-n. The health state parameters of the sub-users 100-n include, but are not limited to, the sub-user creation time, screen locking/unlocking related data, and the like, and the screen locking/unlocking related data take the total unlocking active time, the total unlocking attempt times, the unlocking failure times, and the like as exemplary health state parameters.

Specifically, the sub-user health status management module 1310 may determine the activity level of the corresponding sub-user 100-n based on the sub-user creation time length and the total unlocking activity time length, for example, by calculating a percentage of a ratio of the total unlocking activity time length to the sub-user creation time length to determine the activity level of the corresponding sub-user 100-n, and comparing the activity level with a preset activity threshold to determine the activity level of the sub-user 100-n; the security level of the corresponding sub-user 100-n may be determined based on the total number of attempted unlocking times and the number of failed unlocking times, for example, by calculating a percentage of a ratio of the number of failed unlocking times to the total number of attempted unlocking times to determine a risk-carrying rate of the corresponding sub-user 100-n, and comparing the risk-carrying rate with a preset risk-carrying rate threshold to determine the security level of the sub-user 100-n. Meanwhile, in order to improve the judgment accuracy, a frequency threshold value can be set for the total attempted unlocking frequency, so that the reference values of the activity rate and the data with the risk rate are improved.

It can be understood that, in the case that the total number of attempts to unlock is small, there is a high probability of misjudgment by using the above-mentioned activity rate, the activity level of the child user with the risk rate, and the safety level, and therefore, in this case, the calculation result of the above-mentioned activity rate and the risk rate has no reference value or has a low reference value. As an example, if the threshold of the total number of attempted unlocks for the sub-user 100-n is set to 5 times, i.e., if the total number of attempted unlocks logged by the sub-user 100-n is greater than or equal to 5 times, the sub-user health status management module 1310 does not perform health status evaluation on the sub-user 100-n. Under the condition that the total attempted unlocking times are more than or equal to 5, the lower limit threshold of the activity rate can be preset to be 50%, and the lower limit threshold of the risk rate is preset to be 70%, namely the activity degree of the sub-user with the activity rate more than or equal to 50% is active, otherwise, the sub-user is inactive, the safety degree with the risk rate more than or equal to 70% is risk, and otherwise, the safety degree is safe.

It is to be appreciated that the sub-user health status management module 1310 may determine the activity level and the security level of the sub-user 100-n if the total number of attempts to unlock is sufficient, and then may evaluate the health status of the sub-user 100-n. For example, when the sub-user 100-n is active and safe, the health status of the sub-user 100-n may be assessed as healthy; the health status of a sub-user 100-n may be assessed as unhealthy when the sub-user 100-n is inactive or safe with a risk.

For example, as shown in fig. 7, if the creation time of the sub-user 100-1 is 30 days (d), the total active unlocking time is 29d, the total number of attempts to unlock is 100, and the number of failed unlocking is 0, it may be calculated that the active rate of the sub-user 100-1 is 96.7% > 50%, and the sub-user is active; the sub-user 100-1 has a belt risk ratio of 0 < 70%. Thus, then sub-user 100-1 is active and safe, then sub-user health status management module 1310 may evaluate sub-user 100-1 as a healthy sub-user.

Similarly, if the creation time length of the sub-user 100-2 is 30d, the total unlocking active time length is 15d, the total number of times of unlocking attempts is 50 times, and the number of times of unlocking failure is 20 times, the active rate of the sub-user 100-2 is 50%, and the sub-user is inactive; the sub-user 100-2 has a risk rate of 40% < 70% and is safe; thus, the sub-user health management module 1310 may evaluate the sub-user 100-2 as an unhealthy sub-user.

In addition, since the sub-user 100-3 attempts to unlock the lock for 1 < 5 times, 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.

In other embodiments, other health status parameters may be used to calculate the status characteristic values such as the activity rate, the risk rate, etc. of the sub-user 100-n, for example, the risk rate of the corresponding sub-user 100-n is determined by calculating the percentage of the unlocking success times to the total unlocking attempt times, and the corresponding threshold value of the status characteristic value is set as a reference to evaluate the health status of the sub-user 100-n. And are not intended to be limiting herein.

It can be understood that after the unlocking event is triggered, the mobile phone 100 needs to perform user unlocking authentication before being successfully unlocked, and as described above, the user unlocking authentication manner includes, but is not limited to, entering a PIN code for unlocking, entering a power-on password for unlocking, verifying a fingerprint for unlocking, or performing face recognition for unlocking. It can be understood that, in order to avoid misjudgment of the unlocking failure times, weights may also be set for the various unlocking authentication manners to calculate the unlocking failure times, for example, a weight coefficient for face recognition unlocking is set to 0.2, a weight coefficient for verification fingerprint unlocking is set to 0.3, a weight coefficient for input of a PIN code or input of a boot password unlocking is set to 0.5, a sum of the unlocking times corresponding to the various unlocking authentication manners multiplied by the weight coefficients is calculated, and then the sum result is rounded to obtain a comprehensive unlocking failure times, which is not limited herein.

The class key management module 1400 is configured to determine and generate a loading or discarding instruction of a class key, and send the loading or discarding instruction to the kernel file system 1500 for execution. The user-level class key management module 1410 is configured to perform management operations such as loading or discarding a class key corresponding to a user-level encryption type (including user-level CE/SECE/ECE classes and the like); the device-level key management module 1420 is configured to perform management operations such as loading or discarding device-level keys corresponding to device-level encryption types such as device-level CE/SECE/ECE according to the health status of the sub-user updated by the sub-user status management module 1300, the current screen operating status of the mobile phone 100, and a device-level key call policy. It can be understood that, when the health status and the current screen operating status of the sub-user correspond to the loading policy judgment conditions in the device-level key calling policy corresponding to each device-level encryption type, the device-level key management module 1420 generates a device-level key loading instruction; otherwise, a device-level class key discard instruction is generated.

As an example, in a scenario where the security of the mobile phone 100 configuration is low, the device level class key call policy setting corresponding to each device level encryption type may be as follows:

firstly, for the device-level CE class 1012, if a healthy sub-user unlocks the mobile phone 100, the device-level key management module 1420 generates a device-level key loading instruction corresponding to the device-level CE class 1012, for example, after the device-level key corresponding to the device-level CE class 1012 is loaded, the currently logged-in sub-user 100-1 may access a screenshot stored when logging in by using another sub-user, and the like; if the mobile phone 100 has not been unlocked by the healthy sub-user, the device-level class key management module 1420 generates a discarding instruction of 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 current logged-in sub-user 100-1 cannot access the screenshot stored when logging in by using other sub-users.

For the device-level see 1013 and the device-level ECE 1014, if the currently logged-in sub-user 100-1 of the mobile phone 100 is in a healthy state and the current mobile phone 100 is successfully unlocked, the device-level key management module 1420 generates a loading instruction of the device-level key corresponding to the device-level see 1013 and the device-level ECE 1014, for example, the currently logged-in sub-user 100-1 after loading the device-level key may access historical exercise data stored when logging in using other sub-users; if the currently logged-in sub-user 100-1 of 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 see class 1013 and the device-level ECE class 1014, for example, the currently logged-in sub-user 100-1 cannot access historical motion data stored when logging in by using other sub-users after the device-level class key is discarded.

In a scenario where the security scenario configured by the mobile phone 100 is high, a dual authentication policy may be adopted, and as an example, the policy setting may be invoked for a device-level class key corresponding to a device-level encryption type as follows:

firstly, for the device-level CE class 1012, if the mobile phone 100 is powered on and then another healthy sub-user has successfully unlocked for the first time and the currently logged-in sub-user 100-1 has successfully unlocked for the first time, the device-level key management module 1420 generates a loading instruction of the device-level key corresponding to the device-level CE class 1012; if the first result of the mobile phone 100 is successful when no other healthy sub-user is started or the first unlocking of the currently logged-in sub-user 100-1 is not successful, the device-level class key management module 1420 generates a discarding instruction of the device-level class key corresponding to the device-level CE class 1012.

For the device-level SECE class 1013 and the device-level ECE class 1014, that is, if the mobile phone 100 has a healthy sub-user unlocked 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 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 currently logged-in sub-user 100-1 may access historical exercise data stored when logging by using other sub-users; if the mobile phone 100 is unlocked by an unhealthy 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 see class 1013 and the device-level ECE class 1014, for example, the device-level class key discards the historical motion data stored when the currently logged-in sub-user 100-1 is not accessible to use other sub-users for logging in.

The kernel file system 1500 is configured to receive and execute a user-level class key or device-level class key load/drop instruction sent by the user-level class key management module 1410 or the device-level class key management module 1420. It is understood that the kernel file system 1500 may load the class key based on the access path of the storage location storing the class key in the terminal file system 1000, and the process of discarding the class key is to delete the loaded class key from the kernel file system 1500.

Based on the structure shown in FIG. 6, FIG. 8 is a flow chart of a method for evaluating the health status of the sub-user 100-n. As shown in fig. 8, the process includes:

801: a trigger event is acquired. The processor of the mobile phone 100 runs the corresponding program to execute the screen locking/unlocking module

1200, acquiring a trigger event on the mobile phone 100, where the trigger event on the mobile phone 100 includes a screen locking/unlocking event triggered by operating an on/off key of the mobile phone 100, a screen locking/unlocking event triggered by touching a touch panel of the mobile phone 100, an on event, an off event, and the like, a screen capturing event triggered by operating an on/off key of the mobile phone 100 and a volume key, and details thereof are not repeated here.

802: and judging whether the acquired trigger event is an unlocking event. The processor of the mobile phone 100 executes the corresponding program to execute the function of the screen locking/unlocking module 1200, and determines whether the acquired trigger event on the mobile phone 100 is an unlocking event. The unlocking event includes, but is not limited to, pressing a power-on/power-off key to unlock, clicking a screen locking/unlocking application to unlock, and the like. If the trigger event is an unlocking event, the process is executed 803; if not, then 806 is performed.

803: and judging whether the unlocking event is successful or not. The processor of the mobile phone 100 runs the corresponding program to execute the functions of the screen locking/unlocking module 1200, and determines whether the unlocking event is successful. It can be understood that, after an unlocking event occurs, if the user successfully opens the interface of the mobile phone 100 through correct PIN code authentication, fingerprint authentication, face recognition authentication or other manners, the unlocking event is successfully unlocked; otherwise, the unlocking is unsuccessful. If the unlocking event is successful, executing 804; if not, 805 is performed.

804: and updating the total attempted unlocking times. The processor of the mobile phone 100 runs the corresponding program to execute the function of the sub-user health status management module 1310, adds 1 time to the recorded total unlocking attempt times of the currently logged-in sub-user, and updates the total unlocking attempt times of the currently logged-in sub-user. After this step, execution continues 809.

805: and updating the total attempted unlocking times and the unlocking failure times. The processor of the mobile phone 100 runs the corresponding program to execute the function of the sub-user health status management module 1310, adds 1 time to the recorded total unlocking attempt times of the currently logged-in sub-user, adds 1 time to the recorded unlocking failure times, and updates the total unlocking attempt times and the unlocking failure times of the currently logged-in sub-user. After this step, execution continues 809.

806: and judging whether the acquired trigger event is a screen locking event. The processor of the mobile phone 100 executes the corresponding program to execute the function of the screen locking/unlocking module 1200, and determines whether the acquired trigger event on the mobile phone 100 is a screen locking event. The screen locking event includes, but is not limited to, pressing down/turning off a key to lock the screen, clicking a screen locking/unlocking application to lock the screen, and automatically locking the screen after the mobile phone 100 has no input for a period of time. If the trigger event is a screen locking event, 807 is executed; if not, then 808 is performed.

807: and updating the total unlocking active time length. 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 increases the unlocking active duration before the screen locking this time to the recorded unlocking active total duration of the current login sub-user, and updates the unlocking active total duration of the current login sub-user. After this step, execution continues 809.

808: and ending the process. The processor of the mobile phone 100 runs the corresponding program to execute the function of the screen locking/unlocking module 1200, and does not process the non-screen locking/unlocking event, and settles the process.

809: and updating the creating time length of the sub-user, and determining the active degree and the safety degree of the sub-user. 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 adds the time length updated to the current time last time to the recorded creation time length of the current login sub-user, or calculates the creation time length of the sub-user based on the time difference between the creation time of the currently registered sub-user and the current time.

810: and evaluating the health state of the sub-user, and updating the health state of the sub-user and the current screen working state. The processor of the mobile phone 100 runs a corresponding program to execute the function of the sub-user health state management module 1310, and evaluates the health states of the sub-users based on the total number of attempted unlocking times, the number of failed unlocking times, the total active unlocking time length, and the sub-user creating time length updated in the

above steps

804, 805, and 807, and step 809, where the health state evaluation method of the sub-users refers to the related description of the sub-user health state management module 1310 in fig. 6, and is not described herein again. In addition, the processor of the mobile phone 100 runs a corresponding program to execute the function of the current screen operating state management module 1320, and updates the current screen operating state of the mobile phone 100 based on the current screen locking/unlocking event. It can be understood that the current screen operating state of the mobile phone 100 includes a screen locking state and an unlocking state, which are described above with reference to fig. 7.

It is to be understood that, in other embodiments, the specific implementation of the method flow for evaluating the health status of the sub-user described in the above 801-810 is not limited to be implemented by the respective software structures shown in fig. 6, and may also be implemented by other embodiments, for example, by using a neural network to deeply learn and train the health status evaluation model of the sub-user, which is not limited herein.

The software structure involved in managing the device-level class keys and the method of managing the device-level class keys are described in detail below in conjunction with fig. 9-10.

Fig. 9 shows a block diagram of the relevant software structure for managing device-level class keys in the handset 100. As shown in fig. 9, the related software structures for managing device level class keys include, but are 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. The sub-user state management module 1300 includes, but is not limited to, the sub-user health state management module 1310 and the current screen working state management module 1320, and the functions of the sub-user state management module 1300 and the kernel file system 1500 refer to the related description in fig. 6, which is not described herein again. The device level class key management module 1420 includes, but is not limited to:

a device level key call policy management module 1421, configured to perform management operations such as storing and updating the device level key call policy. Wherein, the device-level class key calling policy refers to a method or a judgment condition for calculating a load/discard device-level class key instruction. The device-level class key invoking policy refers to the description of the class key management module 1400 in fig. 6, which is not described herein again.

The device-level key calling instruction calculation module 1422 takes the health status of the sub-user updated by the sub-user status management module 1300 and the current screen operating status as input, and triggers the device-level key calling policy acquisition module 1421 to acquire a device-level key calling policy, and further calculates to obtain a device-level key loading/discarding instruction, and sends the obtained instruction to the device-level key loading/discarding module 1423.

A device-level key loading/discarding module 1423, configured to receive and execute a device-level key loading/discarding instruction, and trigger the kernel file system 1500 to load or discard the device-level key according to the device-level key loading/discarding instruction executed by the kernel file system.

Fig. 10 is a flowchart illustrating a method for managing device-level class keys. As shown in fig. 10, the flow includes the following steps.

1001: and acquiring the health state of the sub-user and the working state of the current screen. Specifically, the processor of the mobile phone 100 runs the corresponding program to execute the function of the device-level key call instruction calculation module 1422, and obtains the health status of the sub-user and the current screen operating status updated by the sub-user status management module 1300.

1002: and acquiring a device-level class key calling strategy. Specifically, the processor of the mobile phone 100 runs a corresponding program to execute the function of the device-level class key invocation instruction calculation module 1422, and after acquiring the health status of the sub-user updated by the sub-user status management module 1300 and the current screen working status, triggers the device-level class key invocation policy acquisition module 1421 to acquire the device-level class key invocation policy.

1003: and calculating and generating a device-level key loading/discarding instruction based on the acquired health state of the sub-user, the current screen working state and the device-level key calling strategy. Specifically, the processor of the mobile phone 100 runs the corresponding program to execute the function of the device-level key invocation instruction calculation module 1422, takes the health state of the sub-user updated by the sub-user state management module 1300 and the current screen working state as input, and triggers the device-level key invocation policy acquisition module 1421 to acquire a device-level key invocation policy, further calculates a device-level key loading/discarding instruction, and sends the acquired instruction to the device-level key loading/discarding module 1423.

1004: a device-level class key load/discard instruction is executed to load/discard the device-level class key in the kernel file system 1500. If the device-level key loading instruction is executed, 1005 is performed; if a device level class key discard instruction is executed, then 1006 is performed. Specifically, the processor of the mobile phone 100 executes the corresponding program to execute the function of the device-level class key loading/discarding module 1423, receives the loading/discarding instruction sent by the device-level class key invoking instruction calculating module 1422, and executes the instruction to notify the kernel file system 1500 to perform the corresponding device-level class key loading/discarding operation.

Step 1005 is the same as step 304, and step 1006 is the same as step 305, which is not described herein again.

It can be understood that in the method for protecting the device-level sensitive file described in the foregoing steps 301-305, the health status of each sub-user may be re-evaluated each time the mobile phone 100 is re-started, or the health status of each sub-user evaluated after the last startup or before the shutdown is continued in each startup process after the mobile phone 100 leaves factory settings, or the comprehensive health status of each sub-user is obtained by performing weighted calculation on the health status of each sub-user evaluated after the current startup and after the last startup or before the shutdown of the mobile phone 100, for example, the health status of each sub-user evaluated after the last startup or before the shutdown is set with a weight coefficient of 0.2, the health status of each sub-user evaluated after the current startup is set with a weight coefficient of 0.8, and the comprehensive health status of each sub-user is obtained by performing weighted calculation, which is not limited herein.

Fig. 11 shows a schematic structural diagram of the handset 100 according to an embodiment.

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, a Subscriber Identity Module (SIM) card interface 195, and the like. 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, and the like.

It is to be understood that the illustrated structure of the embodiment of the present invention does not specifically limit the mobile phone 100. In other embodiments of the present application, the handset 100 may include more or fewer components than shown, or some components may be combined, some components may be separated, or a different arrangement of components may be used. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

Among other things, processor 110 may include one or more processing units, such as: the processor 110 may include 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), etc. The different processing units may be separate devices or may be integrated into one or more processors.

The controller can generate an operation control signal according to the instruction operation code and the timing signal to complete the control of instruction fetching and instruction execution.

A memory may also be provided in the processor 110 for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may hold instructions or data that have just been used or recycled by the processor 110. If the processor 110 needs to use the instruction or data again, it can be called directly from the memory. Avoiding repeated accesses reduces the latency of the processor 110, thereby increasing the efficiency of the system.

In some embodiments, processor 110 may include one or more interfaces. The interface may include an integrated circuit (I2C) interface, an integrated circuit built-in audio (I2S) interface, a Pulse Code Modulation (PCM) interface, a universal asynchronous receiver/transmitter (UART) interface, a mobile industry processor interface (mobile industry processor interface, MIPI), a general-purpose-microprocessor input/output (GPIO) interface, a SIM interface, and/or a USB interface, etc.

The I2C interface is a bidirectional synchronous serial bus, which includes a serial data line (SDA) and a Serial Clock Line (SCL). In some embodiments, processor 110 may include multiple sets of I2C buses. The processor 110 may be coupled to the touch sensor 180K, charger, flash, camera 193, etc. through different I2C bus interfaces, respectively. For example: the processor 110 may be coupled to the touch sensor 180K through an I2C interface, such that the processor 110 and the touch sensor 180K communicate through an I2C bus interface to implement the touch function of the cell phone 100. For example, the unlocking authentication is completed by verifying the fingerprint information using the touch function of the cellular phone 100.

It should be understood that the interface connection relationship between the modules according to the embodiment of the present invention is only an exemplary illustration, and does not constitute a limitation to the structure of the mobile phone 100. In other embodiments of the present application, the mobile phone 100 may also adopt different interface connection manners or a combination of multiple interface connection manners in the above embodiments.

The charging management module 140 is configured to receive charging input from a charger. The charging management module 140 may also supply power to the electronic device through the power management module 141 while charging the battery 142. The power management module 141 is used 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 may be disposed in the same device.

The wireless communication function of the mobile phone 100 can be realized by the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, the modem processor, the baseband processor, and the like.

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

The mobile communication module 150 may provide a solution including wireless communication of 2G/3G/4G/5G, etc. applied to the handset 100. The mobile communication module 150 may include at least one filter, a switch, a power amplifier, a Low Noise Amplifier (LNA), and the like. The mobile communication module 150 may receive the electromagnetic wave from the antenna 1, filter, amplify, etc. the received electromagnetic wave, and transmit the electromagnetic wave to the modem processor for demodulation. The mobile communication module 150 may also amplify the signal modulated by the modem processor, and convert the signal into electromagnetic wave through the antenna 1 to radiate the electromagnetic wave. In some embodiments, at least some of the functional modules of the mobile communication module 150 may be disposed in the processor 110. In some embodiments, at least some of the functional modules of the mobile communication module 150 may be disposed in the same device as at least some of the modules of the processor 110.

The wireless communication module 160 may provide a solution for wireless communication including Wireless Local Area Networks (WLAN) applied to the mobile phone 100. The wireless communication module 160 may be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, performs frequency modulation and filtering processing on electromagnetic wave signals, and transmits the processed signals to the processor 110. The wireless communication module 160 may also receive a signal to be transmitted from the processor 110, perform frequency modulation and amplification on the signal, and convert the signal into electromagnetic waves through the antenna 2 to radiate the electromagnetic waves. In some embodiments, the antenna 1 of the handset 100 is coupled to the mobile communication module 150 and the antenna 2 is coupled to the wireless communication module 160 so that the handset 100 can communicate with networks and other devices through wireless communication techniques.

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

The display screen 194 is used to display images, video, and the like. The display screen 194 includes a display panel. The display panel may adopt a Liquid Crystal Display (LCD), an organic light-emitting diode (OLED), an active matrix organic light-emitting diode (AMOLED) or an active matrix organic light-emitting diode (active-matrix organic light-emitting diode), a flexible light-emitting diode (FLED), a miniature, a Micro-OLED, a quantum dot light-emitting diode (QLED), and the like. In some embodiments, the mobile phone 100 may include 1 or N display screens 194, with N being a positive integer greater than 1.

The SIM card interface 195 is used to connect a SIM card. The SIM card can be attached to and detached from the cellular phone 100 by being inserted into the SIM card interface 195 or being pulled out from the SIM card interface 195. The handset 100 may support 1 or N SIM card interfaces, N being a positive integer greater than 1. The SIM card interface 195 may support a Nano SIM card, a Micro SIM card, a SIM card, etc. The same SIM card interface 195 can be inserted with multiple cards at the same time. The types of the cards can be the same or different. The SIM card interface 195 may also be compatible with different types of SIM cards. The SIM card interface 195 may also be compatible with external memory cards. The mobile phone 100 interacts with the network through the SIM card to implement functions such as communication and data communication. In some embodiments, the handset 100 employs esims, namely: an embedded SIM card. The eSIM card can be embedded in the mobile phone 100 and cannot be separated from the mobile phone 100.

The software system of the mobile phone 100 may employ a layered architecture, an event-driven architecture, a micro-core architecture, a micro-service architecture, or a cloud architecture. The embodiment of the present invention takes an Android system with a layered architecture as an example, and exemplarily illustrates a software structure of the mobile phone 100.

Fig. 12 is a block diagram of the software configuration of the cellular phone 100 according to the embodiment of the present invention.

The layered architecture divides the software into several layers, each layer having a clear role and division of labor. The layers communicate with each other through a software interface. In some embodiments, the Android system is divided into four layers, an application layer, an application framework layer, an Android runtime (Android runtime) and system library, and a kernel layer from top to bottom.

The application layer may include a series of application packages.

As shown in fig. 12, the application package may include applications such as camera, gallery, calendar, phone call, map, navigation, lock screen, unlock, music, video, short message, etc.

The application framework layer provides an Application Programming Interface (API) and a programming framework for the application program of the application layer. The application framework layer includes a number of predefined functions.

As shown in FIG. 12, the application framework layers may include a window manager, content provider, view system, phone manager, resource manager, notification manager, and the like.

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

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

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

The phone manager is used to provide the communication functions of the handset 100. Such as management of call status (including on, off, etc.).

The resource manager provides various resources for the application, such as authentication data to verify user information during unlocking, localized strings, icons, pictures, layout files, video files, and the like.

The notification manager enables the application to display notification information in the status bar, can be used to convey notification type messages, can disappear automatically after a short dwell, and does not require user interaction. Such as a notification manager used to notify download completion, message alerts, etc. The notification manager may also be a notification that appears in the form of a chart or scroll bar text at the top status bar of the system, such as a notification of a background running application, or a notification that appears on the screen in the form of a dialog window. For example, the prompt information of the unlocking failure shown in fig. 8 may be added with notification modes such as a prompt sound, vibration of the electronic device, and blinking of an indicator light.

The Android Runtime comprises a core library and a virtual machine. The Android runtime is responsible for scheduling and managing an Android system.

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

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

The system library may include a plurality of functional modules. For example: surface managers (surface managers), Media Libraries (Media Libraries), three-dimensional graphics processing Libraries (e.g., OpenGL ES), 2D graphics engines (e.g., SGL), and the software modules shown in FIGS. 6 and 10 above, among others. It is to be understood that the software modules shown in fig. 6 and 10 can also be disposed at the application framework layer, and are not limited herein.

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

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

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

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

The kernel layer is a layer between hardware and software. The inner core layer at least comprises a display driver, a camera driver, an audio driver and a sensor driver.

The workflow of the software and hardware of the mobile phone 100 is exemplarily described below with reference to a screen locking/unlocking scenario.

When the button 190 receives a screen locking/unlocking operation by pressing or the touch sensor 180K receives a touch screen locking/unlocking operation, the screen locking/unlocking application located in the application layer is triggered to be opened. And after the screen locking/unlocking application is started, screen locking/unlocking notifications are sent to the application framework layer, the system library and the kernel layer by layer. And sending a corresponding hardware operation notification to the kernel layer, wherein the kernel layer processes the screen locking/unlocking operation into an original input event (comprising information such as screen locking/unlocking events and corresponding timestamps). The raw input events are stored at the kernel layer. And the application program framework layer or the system library acquires 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 by the processor 110 of the handset 100 to be implemented in the application framework layer or system library.

Reference in the specification to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one example embodiment or technology 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.

The present disclosure also relates to an operating device for performing the method. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, magnetic-optical disks, read-only memories (ROMs), Random Access Memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, Application Specific Integrated Circuits (ASICs), or any type of media suitable for storing electronic instructions, and each may be coupled to a computer system bus. Further, the computers referred to in the specification may include a single processor or may be architectures employing multiple processor designs for increased computing capability.

The processes and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may also be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform one or more method steps. The structure for a variety of these systems is discussed in the description that follows. In addition, any particular programming language sufficient to implement the techniques and embodiments disclosed herein may be used. Various programming languages may be used to implement the present disclosure as discussed herein.

Moreover, the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the disclosed subject matter. Accordingly, the present disclosure is intended to be illustrative, but not limiting, of the scope of the concepts discussed herein.

Claims

1. A device-level sensitive file protection method is applied to electronic equipment, and a plurality of sub-users log on the electronic equipment, and is characterized by comprising the following steps:

evaluating the health states of the sub-users and acquiring the screen working state of the electronic equipment; wherein the health status is used at least to describe a safety level of the sub-user;

obtaining a device-level class key calling strategy to determine the type of calling the device-level class key, wherein the device-level class key is used for accessing the device-level sensitive file;

determining to load the device-level class key or discard the device-level class key based on the health states of the plurality of sub-users, the screen working state of the electronic device, and the device-level class key calling policy;

wherein the loading the device-level class key comprises copying the device-level class key to a kernel file system of the electronic device; discarding the device-level class key may include deleting the device-level class key from a kernel file system of the electronic device.

2. The method of claim 1, wherein determining to load or discard the device-level class key based on the health status of the plurality of sub-users, the screen operational status of the electronic device, and the device-level class key invocation policy comprises:

determining to load the device-level class key under the condition that the health states of the sub-users and the screen working state of the electronic device conform to a device-level class key loading strategy in the device-level class key calling strategy;

and determining to discard the device-level class key under the condition that the health states of the plurality of sub-users and the screen working state of the electronic device do not accord with the device-level class key loading strategy.

3. The method of claim 2, wherein the health status is further used to describe the activity level of the sub-user;

the device-level class key comprises a first device-level class key, a second device-level class key and a third device-level class key;

the screen working state comprises a screen locking state or an unlocking state, wherein the unlocking state comprises an unlocking success state in which unlocking authentication is successfully completed after an unlocking event is triggered and an unlocking failure state in which the unlocking authentication is not successfully completed.

4. The method of claim 3, wherein the device-level class key loading policy comprises one of:

loading the first device-level key when the first unlocking state of the electronic device is the unlocking success state after any healthy sub-user in the plurality of sub-users logs in the electronic device;

loading the first device-level key under the condition that the first unlocking state after any healthy sub-user logs in on the electronic device is the unlocking success state and the first unlocking state after the first sub-user logs in on the electronic device is the unlocking success state;

loading the second device-level class key or the third device-level class key when a first healthy sub-user of the plurality of sub-users logs in the electronic device currently and the current screen working state of the electronic device is the unlocking success state;

the unlocking state after any healthy sub-user logs in on the electronic equipment at least comprises the unlocking success state once, and the second equipment-level key or the third equipment-level key is loaded under the condition that the current unlocking state of the first healthy sub-user currently logged in on the electronic equipment is the unlocking success state;

wherein the plurality of sub-users includes the any healthy sub-user, the first healthy sub-user, and the first sub-user.

5. The method of claim 4, wherein the evaluating the health status of the plurality of sub-users comprises:

acquiring a health state parameter of a first sub-user of the plurality of sub-users, wherein the health state parameter is at least used for calculating the activity degree and the safety degree of the sub-user; and is

And under the condition that the health state parameter of the first sub-user meets a preset threshold value condition, evaluating that the sub-user is a healthy sub-user.

6. The method of claim 5, wherein the health status parameters comprise a sub-user creation time of the first sub-user, a total number of attempts to unlock, a number of failed to unlock, or a number of successful to unlock, and a total active time of unlocking when the first sub-user is logged on to the electronic device; wherein the content of the first and second substances,

the total attempted unlocking times are times of triggering unlocking events, the unlocking failure times are times of occurrence of the unlocking failure state, and the unlocking success times are times of occurrence of the unlocking success state.

7. The method of claim 6, wherein the evaluating the health status of the plurality of sub-users further comprises:

determining the activity degree of the first sub-user to be active under the condition that the ratio of the total unlocking activity duration to the first sub-user creating duration is greater than or equal to a preset activity threshold value;

when the total attempted unlocking time is greater than or equal to a preset time threshold value, and

determining the safety degree of the first sub-user as safety under the condition that the ratio of the unlocking failure times to the total attempted unlocking times is less than or equal to a preset threshold with risk rate; or alternatively

Determining the safety degree of the first sub-user as safety under the condition that the ratio of the unlocking success times to the total attempted unlocking times is greater than or equal to a preset success rate threshold;

determining that the first sub-user is a healthy sub-user if the first sub-user is active and safe.

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

9. A computer-readable storage medium having stored thereon instructions that, when executed on a computer, cause the computer to perform the device-level sensitive file protection method of any of claims 1 to 7.

10. An electronic device comprising one or more processors; one or more memories; wherein the content of the first and second substances,

the one or more memories store one or more programs that, when executed by the one or more processors, cause the electronic device to perform the device-level sensitive file protection method of any of claims 1-7.