A multi-user partition isolation method based on security chip

Abstract

The present invention provides a multi-user partition isolation method based on a security chip. The primary user uses native processes, and all data is stored in the data partition. When a new user is created, the system divides the partition into independent cells at the hardware level. All data of all newly created users is stored in the independent partition. Users cannot access each other's data across physical partitions, thus ensuring data security. The beneficial effects of the present invention are: This technical solution combines a security chip and multi-user technology to set up an independent system partition, physically separating it from the system and isolating the data to prevent user data leakage. At the same time, it restricts access rights to ensure the security of system partition data, provides data encryption services, and improves the data security level. In addition, it provides a self-destruct function to fundamentally prevent the theft of partition data and ensure the security of user information.

Description

Technical Field

[0001] The present invention relates to the technical field of intelligent terminals, and in particular to a multi-user partition isolation method based on a security chip. Background Art

[0002] With the rapid development of information technology, the Android system has been continuously iterated. Android 8.0 and above have been continuously optimized, making the system more stable and fluid. However, this still presents various security issues. The Android operating system is open source, making it more vulnerable to attacks and viruses than closed mobile operating systems like iOS, and it also lacks comprehensive protection mechanisms against data leaks. Given the significant security risks facing terminal systems, the addition of security applications to the native Android system is a solution that has led to the emergence of dual operating systems.

[0003] Currently, there are four main types of dual-OS solutions: dual-OS solutions based on Linux account technology (referred to as dual users), multi-OS solutions based on Android service transformation technology (referred to as security domains), dual-OS solutions based on container technology (referred to as dual-OS), and dual-OS solutions based on virtual machine technology (referred to as virtual machines). These dual-OS solutions achieve internal system data security through data isolation strategies at the software or hardware level.

[0004] Currently, multi-user features in dual operating systems use the same partition for multiple users, without physical isolation. All data, including system and application data, resides in the same / data partition, making it highly vulnerable to data leakage and extremely insecure. Furthermore, multi-user systems lack strong privacy features and lack any other means of data security reinforcement. Any data in files can be manipulated, and data is not encrypted, posing a significant risk of data leakage. Summary of the Invention

[0005] This invention combines a security chip with multi-user partitioning technology to physically isolate the data of each user within a multi-user system, storing non-zero user data in independent partitions. This ensures partition isolation requirements between users from the software to the hardware level. The security chip's encryption and decryption technology encrypts and protects the independent partitions and partition files, enhancing user data security. The security chip utilizes a domestic cryptographic algorithm, ensuring algorithmic security and user data security. The system also incorporates a self-destruct mode. When certain conditions are met, the system invokes a self-destruct module to format the partition data associated with the new user, including personal data and the partition file system. This fundamentally prevents the leakage of user private data and protects the security of user privacy information. This invention is implemented through the following technical solutions.

[0006] A multi-user partition isolation method based on a security chip. The primary user uses native processes, and all data is stored in the data partition. When a new user is created, the system divides the partition into independent cells at the hardware level. All data of all newly created users is stored in independent partitions. Users cannot access each other's data across physical partitions, ensuring data security.

[0007] The beneficial effects of the present invention are: compared with the existing technology, the present invention creates independent partitions for multiple users, isolates system users from each other from the physical bottom layer, protects user data security, and at the same time verifies the mounting of partitions through the encryption verification technology provided by the security chip to ensure the safe mounting of partitions.

[0008] The present invention is based on trusted computing technology, SELinux technology, system-level application operating environment isolation technology, multi-user technology and equipment security management technology with information leakage prevention as the core, to realize a dual operating system environment and achieve the purpose of application and data security isolation.

[0009] The partition system can be destroyed by triggering a password to quickly clear the system partition storage and the use traces of the partition system, protecting the system from leakage and data theft.

[0010] The algorithm capability in the security chip is provided by the encryption chip hardware IP core. All encryption operations are completed in the IP core, which can effectively resist various forms of attacks. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 It is a native multi-user partition structure diagram of the existing technology.

[0012] Figure 2 It is a structural diagram of the independent partition multi-user of the present invention.

[0013] Figure 3 It is a schematic diagram of independent partitions of the present invention.

[0014] Figure 4 This is a schematic diagram of the native Selinux security framework of the present invention.

[0015] Figure 5 This is a schematic diagram of the Selinux security framework after using independent partitions in the present invention.

[0016] Figure 6 This is a flowchart of starting and verifying the independent partition of the system of the present invention.

[0017] Figure 7 It is a partition destruction flow chart of the present invention.

[0018] Figure 8 It is the FBE flow chart of the present invention. DETAILED DESCRIPTION

[0019] The embodiments of the present invention are described in detail below with reference to the accompanying drawings. However, the present invention can be implemented in many different ways as defined and covered by the claims.

[0020] like Figure 1 As shown in the figure, in the existing technology, when creating a multi-user system, the data of all users (including master user 0) is stored in the same data partition. Separate directories are created based on user IDs, and data generated by individual applications and shared data are all stored in the data directory (for example, shared data is stored in the / data / media directory). All users use the same partition, and data is not isolated. This model lacks data security and can easily lead to user data leakage and theft.

[0021] like Figure 2 As shown in the figure, it is a partition structure diagram of multiple users after the present invention uses independent partitions. The original multiple users are partitioned and isolated. The main user No. 0 uses the original process, and all data is stored in the data partition. Another independent partition (cells) is created. When a new user is created, the system divides an independent partition from the hardware level. All new users (taking 10 users as an example) and all data of the 10 users are stored under the independent partition. Users cannot access each other's data across physical partitions to ensure data security.

[0022] like Figure 3 The following is a schematic diagram of partition usage. Different from the primary user 0, non-user 0 uses an independent partition called cells. When compiling the system source code, cells.img (partition image) is generated. When allocating partitions, the required size is allocated. The cells partition initialization directory is configured in init.rc (initialization startup file).

[0023] cells / user|user_de The user directory stores apps and data of new partition users

[0024] The cells / system|system_ce|system_de directory stores the relevant system setting data of the new partition users

[0025] The cells / vendor_ce|vendor_de directory stores the manufacturer's customized data

[0026] The cells / misc|misc_ce|misc_de directories store boot recovery information and key configuration data

[0027] The cells / media directory stores the shared storage directory of applications, such as pictures, videos, downloads, and other media content.

[0028] When the Android system starts and parses the init.rc file, it will create the above-mentioned directories and configure the corresponding selinux (security policy).

[0029] Taking the Android system as an example, in order to achieve the normal use of the new partition based on Android 11, it is necessary to modify the key processes of the system. The specific implementation is as follows:

[0030] Android system's System layer:

[0031] Add the relevant structure of the cells directory to the rootdir (root directory), add the creation of related directories such as cells / mediauser system vendor in init.rc, and add a global property pointing to the cells root directory in init.environ.rc.in (initialization environment configuration file). The logical modification here is mainly to create the cells-related directories when the init process is pulled up to perform system initialization and parse the rc file after the kernel is started.

[0032] Add relevant logic to init.rc to implement the interaction between init and the security chip when mounting cells.img. Cells.img can be mounted only after successful verification by the security chip. At the same time, add security policy verification to the selinux (security policy) logic of init to perform security checks on the secontext (security context) of the cells directory.

[0033] A new cells root directory interface has been added to vold (storage management service). The system's primary user (user 0) returns a file path with / data as the root directory, while all newly created non-user users return a file path with / cells as the root directory. For example, for user 10, the media directory returns / cells / media / 10. Furthermore, when mounting a volume, the newly created user mounts the cells / media shared media directory. For emulated volumes, a dedicated directory, / mnt / cellsrutime, and related subdirectories are created for the new user to distinguish them from the primary user.

[0034] For the Android system's FBE feature, since the FBE key cannot be used for cross-partition encryption and unlocking, the relevant logic needs to be modified. This involves modifying the logic in fscrypt (file encryption and decryption) to implement its own encryption and unlocking process for each new partition to adapt to the partition's FBE (File-Based Encryption) functionality.

[0035] In sdcard (external storage management), related logic has been added for the mounting of the mnt (cache) directory. When mounting a new user's partition directory, the sdcardfs (external storage file management service) mechanism uses related directories such as " / mnt / cellsruntime / default / ", " / mnt / cellsruntime / read / ", " / mnt / cellsruntime / write / ", and " / mnt / cellsruntime / full / " to adapt to the new partition. Ultimately, these related directories will be mounted to the cells / media shared media directory.

[0036] Add a file_context (file context entity) for the cells directory to the Android system's sepolicy (security policy). Use the cells_file context to manage the security context of all directories and files in the newly created partition. Separate security contexts are also added for several related directories within the cells directory (such as system, user, and vendor). Add an allow rule for cells_file to related policy entity files (such as system_server, zygote, voldinit, and install).

[0037] In the version sepolicy (security policy) (device / mediatek / sepolicy), add corresponding block_device (block device) for the partition ( / dev / block / platform / mtk-\b(msdc|ufs)\b\.0 / [0-9]+\.\b(msdc0|ufs0)\b / by-name / cells and / dev / block / by-name / cells), configure the rules related to this block_device, and add support for the relevant rules of cells block_device in related te such as initfsck e2fs resize.

[0038] In libselinux (security policy library) in External (Android source code extension), security policy processing logic for partition-related directories such as cells / user has been added.

[0039] Android system framework layer:

[0040] Modify the multi-user logic related to zygote (incubation process). When zygote performs isolateAppData (application data separation method), the ce and de directories of the new user are returned to the partition directory (cells / usercells / user_de) according to the userid, and the context of the partition directory is relabeled.

[0041] In the environment system environment variable, add the getCellsDirectory method to return the partition root directory. At the same time, add a new non-zero user to return the corresponding directory and subdirectories with cells as the root when obtaining the directory (such as system user user_de).

[0042] The installd service (installation service) is modified synchronously with the vold service. New users are returned to the new partition root directory and related directories and subdirectories. The logic related to new users in InstallNativeService is modified synchronously to adapt to the new partition.

[0043] Android system Build (construction) related:

[0044] Add relevant logic to Build to generate the cells directory and cells.img. According to the current version rules, add rules for generating cells images in related scripts such as Makefile build_image.py common.py add_img_to_target_files.py. In this way, an independent cells image is generated after the whole system is compiled.

[0045] In the BoardConfig of the current version (for example, device / mediatek / mtxxxx), add global parameters for the cells partition. In the init.mtxxxx.rc and factory_init.rc / meta_init.rc file, add permissions and ownership for the / cells partition directory. At the same time, perform restorecon_recursive on the / cells directory.

[0046] In the current version of fstab, add the mount of the DEVPATH(cells) / cells root directory and configure the partition format to ext4.

[0047] In the ptgen partition (partition division) table partition_table_emmc.csv, add the cells partition, cells,EXT4,61457280,,EMMC_USER,UFS_LU2,,N,Y,cells.img,N,N,Y,,Y,,AUTO, and configure the partition size according to actual needs (the cells partition must be configured before the data primary partition).

[0048] Android system FBE (File-Based Encryption based on file encryption and decryption) related:

[0049] For the FBE function of the Android system, since the key of the FBE function cannot be encrypted and unlocked across partitions, the relevant logic needs to be modified.

[0050] like Figure 8 As shown, the FBE (File-Based Encryption) process needs to be modified accordingly for the new partition. In the current version of fstab, when mounting the cells partition, configure the relevant fbe encryption mode.

[0051] In init.rc, add installkey for the cells partition. When the init process parses the rc file, it parses the encryption method of the cells partition according to the cells installkey, uses the keymaster key to encrypt and generate the global keys of the cells partition (the key of user 0 is stored in / data / unencrypted / key, and the key of new user 10 is stored in / cells / unencrypted / key), and adds the generated keys to the keyring.

[0052] When the init process performs user initialization, it generates user-mode CE DE keys (keys for user authentication association and device encryption) and stores them in corresponding directories (different directories are used for user 0 and newly created user 10: user 0 uses the native / data directory and subdirectories, while user 10 uses the new partition directory / cells and related subdirectories). After the key is generated, it is added to the keyring.

[0053] The multi-user process in Fscrypt (file encryption and decryption) has been modified. When a new user uses independent partition cells, the relevant CE and DE directories are created (for example, / cells / media / 10 / cells / system_ce / 10 / cells / user_de / 10 / cells / system_de / 10 and other related directories) and the relevant encryption policy (key ref) is set.

[0054] During the startup process, the new user uses the key generated by the above process to decrypt and use the CE DE space.

[0055] like Figure 4-Figure 5 The following is a comparison of the Selinux security framework between native and independent partitions.

[0056] The native Android system Selinux security framework is as follows Figure 4 As shown in the figure, the relevant security context and rules are configured through the sepolicy (security policy) module in the user space. At the same time, the security service runs through the entire framework layer. During the operation of services such as zygote initvoldinstall, security checks and context checks and matches are initiated to the libselinux library (security policy library), and finally enters the kernel space security policy file system for the final security check.

[0057] In native multi-user mode, all users are in the / data partition. When using independent partitions, a separate security context is required. The security framework for independent partitions is as follows: Figure 5 As shown in the figure, in the user space security context configuration policy (add the security context cells_file related to the new partition in the sepolicy module, and because the cells partition is an independent block device, the related cells_block_device needs to be configured). When configuring the context, a series of security rules need to be added on different te entities for the newly added security context.

[0058] At the same time, for multiple users based on the new partition, corresponding process changes need to be made for the new partition in the new user creation and startup process. When creating a new user in zygote (incubation process), it is necessary to add relabel of related directories such as / cells / user (relabel when creating application directories for new users). When locking and unlocking emulate in vold, it is necessary to add setfilecon (set file security context) and restorecon (reload file security context) to the new partition directory. When a new user creates application data in the installd service, it is necessary to restorecon_app_data based on the new partition directory.

[0059] The libselinux core security service library provides security context operation methods (such as setfilecon and restorecon) for the above-mentioned zygote, vold, and installd services. The method (pkgdir_selabel_lookup) for handling new partition cells in libselinux is modified to adapt to operations such as creating multi-user application directories in the new partition.

[0060] like Figure 6 The following is a flowchart of independent partition startup and use, including the following steps:

[0061] When the system creates multiple users, the system startup process for each user is basically the same. The main difference is that the file system is mounted in different locations and the mounting of independent partitions needs to be verified by the security chip to ensure the security of non-zero users. The specific process is as follows:

[0062] During Android startup, after parsing init.rc, a cells folder is created in the Android system root directory.

[0063] The Ext4 file format cells.img image is read from the corresponding cells partition location in the ROM (read-only memory). The working system partition loader calculates the hash value of cells.img and compares it with the hash stored in the security chip. If the comparison is successful, the signature value of cells.img is verified. If the signature verification passes, the cells image is parsed. The cells.img image file format is parsed, and information related to the cells.img image is read from the superblock, including the file system status, file system type, size, number of blocks, number of inodes, etc.

[0064] After successfully parsing the cells.img image, mount cells.img to the cells directory. After the cells are successfully mounted, create directories related to the working system under the cells directory. At the same time, the system selinux (security policy) service uses cells as the rootfs, configures the secontext (security context) of cells, and configures the secontext (security context) of each subdirectory under the cells directory according to the rules.

[0065] The above steps complete the partition directory related work. After the user creates a new user in the UI interface, the user creation process begins.

[0066] When creating a user (for example, creating user ID 10), UMS (UserManagerService) creates a user-specific directory by calling the installd service. Finally, vold completes the creation of each user directory (cells / user / 10cells / user_de / 10cells / media / 10, etc.). After the creation of each user directory is completed, it starts to install apps to the corresponding directory.

[0067] After the application is installed, UMS starts to launch various applications through system_server (system service), starts the desktop and enters the user system.

[0068] like Figure 7 The following is the partition destruction process:

[0069] The multi-user system is designed based on the system security policy and can be destroyed in special scenarios to protect the user's personal private data from being stolen.

[0070] Design the destruction trigger method. The system settings interface provides relevant settings and sets a destruction password. When the user enters the corresponding destruction password on the lock screen interface, destruction can be triggered.

[0071] When destroying data, the system's user directory and application data will be cleared, the entire system partition cells will be formatted, and all data will be cleared and unusable.

[0072] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Those skilled in the art will readily appreciate that various modifications and variations of the present invention are possible. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention shall be included within the scope of protection of the present invention.

Claims

1. A multi-user partition isolation method based on a security chip, characterized in that: The primary user uses the native process, and all data is stored in the data partition. When a new user is created, the system allocates an independent partition cell at the hardware level. All data of all newly created users is stored in the independent partition. Users cannot access each other's data across physical partitions, ensuring data security. The new user uses independent partition cells. When compiling the system source code, cells.img is generated and the required size is allocated when allocating partitions. The cells partition initialization directory is configured in init.rc, where: cells / user|user_de The user directory stores apps and data of users in the new partition; The cells / system|system_ce|system_de directory stores the corresponding system setting data of the new partition users; The cells / vendor_ce|vendor_de directory stores the corresponding data of the manufacturer's customized part; The cells / misc|misc_ce|misc_de directories store boot recovery information and key configuration data. The cells / media directory stores the shared storage directory for applications. When a new user is created, the partition cells create directories: add the corresponding structure of the cells directory in rootdir, create the cells / media user system vendor corresponding directory in init.rc, and add a global attribute pointing to the cells root directory in init.environ.rc.in; Add corresponding logic in init.rc to implement the interaction between init and the security chip when mounting cells.img. Cells.img can only be mounted after the security chip has successfully verified it. A new cells root directory interface has been added to Vold. The system's main user returns a file path with / data as the root directory, while all new users return a file path with / cells as the root directory. Modify the logic in fscrypt to adapt to the FBE process of partitions; Added corresponding logic for the mount of the mnt directory in Sdcard. When mounting the partition directory of a new user, the sdcardfs mechanism uses the corresponding directories " / mnt / cellsruntime / default / ", " / mnt / cellsruntime / read / ", " / mnt / cellsruntime / write / ", and " / mnt / cellsruntime / full / ". Add the file_context of the cells directory to the system sepolicy. Use cells_file as the context to control the security context of all directory files in the newly created partition. Add a separate security context for the corresponding home directory of the cells directory and add an allow rule for cells_file in the corresponding te file. In the sepolicy version, add a corresponding block_device for the partition and configure the rules corresponding to this block_device; For initfsck, e2fs, and resize, add support for cells block_device rules in the corresponding te files; In External libselinux, add security policy processing logic for the partition corresponding directory cells / user.

2. A multi-user partition isolation method based on a security chip according to claim 1, characterized in that: When the system starts, when parsing the init.rc file, the above corresponding directories will be created and the corresponding selinux will be configured.

3. The multi-user partition isolation method based on a security chip according to claim 1, characterized in that: When a new user is created, modifications are also made to the corresponding multi-user logic of zygote. When zygote isolates AppData, it returns the partition directory based on the userid, the ce and de directories of the new user, and relabels the context of the partition directory. In the environment system environment variable, add the getCellsDirectory method to return the partition root directory. At the same time, when a newly created non-primary user obtains a directory, the corresponding directory and subdirectories with cells as the root are returned. The Installd service is modified synchronously with the vold service. The new user returns the new partition root directory and corresponding directories and subdirectories. The logic corresponding to the new user in InstalldNativeService is modified synchronously to adapt to the new partition.

4. The multi-user partition isolation method based on a security chip according to claim 1, characterized in that: When creating a new user, the system Build is also modified to add the corresponding logic to generate the cell directory and cells.img. According to the current version rules, the rules for generating cell images are added to the corresponding scripts of Makefile, build_image.py, common.py, and add_img_to_target_files.py. In this way, after the whole system is compiled, an independent cell image is generated. In the current version, the global parameters of the partition cells are added. The permissions and ownership of the / cells partition directory are added to the version rc files init.mtxxxx.rc, factory_init.rc, and meta_init.rc. At the same time, restorecon_recursive is performed on the / cells directory. In the current version of fstab, add the mount of the DEVPATH / cells root directory and configure the partition format to ext4; Use ptgen to add the cells partition in the partition_table_emmc.csv partition table and configure the partition size according to actual needs.

5. The multi-user partition isolation method based on a security chip according to claim 1, characterized in that: When a new user is created, the FBE process is also modified: Add an installkey for the cells partition in init.rc. When the init process parses the rc file, it parses the encryption method of the cells partition according to the cells installkey, encrypts the generated global keys of the cells partition using the keymaster key, and adds the generated keys to the key ring. When the init process performs user initialization, it generates user-state CE key and DE key, and stores the keys in the corresponding directories. After the keys are generated, they are added to the keyring. The multi-user processing flow in Fscrypt has been modified accordingly. When a new user uses independent partition cells, the corresponding CE and DE directories are created and the corresponding encryption policy is set.

6. The multi-user partition isolation method based on a security chip according to claim 1, characterized in that: When creating a new user, the security context and rules are also configured in the sepolicy module. At the same time, the security service runs through the entire framework layer and initiates security checks and context checks and matches to libselinux during the operation of zygote, initvold, and install services, and finally enters the kernel space Selinux file system for the final security check.

7. The multi-user partition isolation method based on a security chip according to claim 6, characterized in that: Configure security contexts and rules in the new user space. Add the security context cells_file corresponding to the new partition in the sepolicy module. At the same time, because the cells partition is an independent block device, you need to configure the corresponding cells_block_device. When configuring the context, you need to add a series of security rules on different te entities for the newly added security context. At the same time, for multiple users based on the new partition, the process of creating and starting new users needs to be changed accordingly for the new partition. When creating a new user in zygote, it is necessary to add the relabel of the directory corresponding to / cells / user. When locking and unlocking emulate in vold, it is necessary to add setfilecon and restorecon to the new partition directory. When creating application data for a new user in the installd service, it is necessary to perform restorecon_app_data based on the new partition directory. The libselinux core security service library provides corresponding security context operation methods for the above-mentioned zygote, vold, and installd services. In libselinux, the pkgdir_selabel_lookup method for handling new partition cells is added to adapt to the creation of multi-user application directories in new partitions.

8. The multi-user partition isolation method based on a security chip according to claim 1, characterized in that: The specific process of creating multiple users in the system is as follows: During system startup, after parsing init.rc, a cells folder is created in the Android system root directory; Read the Ext4 file format cells.img image from the cells partition location corresponding to the ROM; After successfully parsing the cells.img image, mount cells.img to the cells directory. After cells are successfully mounted, create a directory corresponding to the working system under the cells directory. At the same time, the system selinux service uses cells as the rootfs, configures the cells's secontext, and configures the secontext of each subdirectory under the cells directory according to the rules.

Images