Method for dynamic access control of encrypted disk based on integrity of system critical files

Abstract

The application relates to a method for dynamic access control of an encrypted disk based on system key file integrity, and belongs to the field of operating system security, which comprises the following steps: constructing a LUKS encrypted disk with access permission control, and configuring a read-only user key and a read-write user key; performing integrity measurement on a starting component through TPM trusted hardware, and obtaining the read-only user key after the measurement; performing integrity measurement on a system key file through a TEE security world, and deriving the read-write user key by using an HMAC key in the TEE security world after the measurement; continuously monitoring an audit log of IMA, and verifying the integrity of the key file based on preset spot-check rules when the measured file in the audit log is the key file; and automatically adjusting the access permission of the LUKS encrypted disk if the integrity of the key file is destroyed. The application has the effect of improving the security of data.

Description

Technical Field

[0001] This application relates to the field of operating system security, and in particular to a method for dynamic access control of encrypted disks based on the integrity of critical system files. Background Technology

[0002] With the rapid development of information technology, data security has become paramount. Disk encryption is a crucial means of protecting data security. Common disk encryption schemes, such as LUKS (Linux Unified Key Setup), encrypt the disk using a key, allowing only the user holding the key to access the disk data. However, traditional disk encryption schemes fail to provide sufficient protection when system integrity is compromised. For example, if critical system files are tampered with, attackers could exploit these files to obtain disk keys or disk access permissions, thereby stealing or tampering with sensitive data. Disk encryption and system integrity protection are independent of each other and lack a collaborative mechanism.

[0003] In existing technologies, such as Windows BitLocker, disk encryption is implemented based on TPM (Trusted Device Manager) hardware. The disk key is securely stored within the TPM hardware by binding to the integrity state of the system boot components. To unlock the disk using the user key stored in the TPM, the integrity of the system boot components must be intact. Only if the integrity of the system boot components is intact will the TPM release the user key and provide it for successfully unlocking the encrypted disk. However, the data security and key security of the encrypted disk are only related to the integrity of the system boot components. The integrity security of critical files running in the production environment is not addressed. If critical files running in the production environment are tampered with, it can lead to disk key leakage, disk data leakage, or tampering.

[0004] Once the system is running, the environment becomes dynamic and complex. A one-time critical file integrity check after startup is not sufficient because system files are at risk of being tampered with at any time. Currently, there is a lack of encrypted disk protection mechanisms for dynamic detection of critical file integrity during system operation.

[0005] Patent CN113806787A provides a method for automatic decryption on an ARM platform. The method splits the user key into two parts: one part is stored on a remote server, and the other part is stored in the TEE's FTPM. Measurement data obtained during server firmware startup is compared with a benchmark value; if they match, both parts of the key are successfully obtained, thus unlocking the encrypted disk. This invention effectively ensures flexible data security management; however, it only focuses on the integrity of startup components during firmware startup. It lacks effective attention and control measures for the integrity of critical files during system operation. Attackers can still obtain the unlocked disk key and access and tamper with disk data after modifying critical system files.

[0006] Patent CN114239091A discloses a disk encryption method based on a trusted chip. The method involves writing an encryption key into a trusted chip of the system to be encrypted and adding a token to bind a LUKS key slot to the trusted chip. The token stores the method by which the encryption key was written to the trusted chip and the associated LUKS key slot. While this method binds the key to the trusted chip to ensure key security, it only stores the key within the trusted chip and does not provide comprehensive protection for the key. It also does not address the integrity checks of critical system files. If critical system files are tampered with by an attacker, the attacker can directly obtain the key stored in the trusted chip.

[0007] Therefore, a solution is needed that can dynamically adjust disk access permissions based on the integrity status of the system at each stage of its lifecycle, so as to restrict disk access when system integrity is compromised, thereby reducing the risk of data leakage. Summary of the Invention

[0008] To improve data security, this application provides a method for dynamic access control of encrypted disks based on the integrity of critical system files.

[0009] This invention provides a method for dynamic access control of encrypted disks based on the integrity of critical system files, the method comprising:

[0010] Step S1: In the system pre-configuration phase, a LUKS encrypted disk with access control is constructed, and two types of user keys are set. At the same time, TEE Security World generates a metric list containing benchmark values ​​based on key files. The two types of user keys are read-only user keys and read-write user keys. The read-only user keys are used to unlock the LUKS encrypted disk with read-only permissions, and the read-write user keys are used to unlock the LUKS encrypted disk with read-write permissions.

[0011] Step S2: During the system operation phase, prioritize obtaining the read / write user key. If successful, unlock the LUKS encrypted disk with read / write permissions and proceed to step S4. If failure occurs, proceed to step S3.

[0012] Step S3: Obtain the read-only user key. If successful, unlock the LUKS encrypted disk with read-only permissions. If unsuccessful, the process ends.

[0013] Step S4: Use IMA to monitor all files and generate audit logs. Filter the audit logs for critical files through the REE normal world and send them to the TEE security world after calculating the third metric hash value. The TEE security world will then check and verify the integrity of the critical files based on preset sampling rules. If the verification is inconsistent, the access permissions of the LUKS encrypted disk will be automatically downgraded from read / write permissions to read-only permissions. If the verification is consistent, the current access permissions will be maintained.

[0014] The TEE secure world is used to process sensitive data and ensure the confidentiality and integrity of the code and data loaded into the TEE secure world;

[0015] The security of the REE normal world is lower than that of the TEE secure world. The REE normal world and the TEE secure world coexist and communicate with the TEE secure world through a specific interface.

[0016] The IMA is a system runtime file integrity protection mechanism that can perform measurements during file execution and loading.

[0017] Optionally, step S1 includes:

[0018] Step S11: Generate a random key through the TPM trusted hardware, use the random key as the read-only user key, and seal it through the TPM trusted hardware; use the HMAC key generated by TEE Security World to derive a key from the read-only user key, and use the derived key as the read-write user key; the TPM trusted hardware has the function of providing integrity measurement and key management through hardware-level security chip.

[0019] Step S12: Encrypt the master key generated for building the LUKS encrypted disk using the configured read-only user key and read-write user key, and then store it in different key slots in the header metadata area of ​​the LUKS encrypted disk;

[0020] Step S13: Add an access control field to the LUKS token corresponding to each key slot to record the permissions of the keys in the key slot corresponding to the LUKS token;

[0021] Step S14: TEE Security World generates a benchmark value metric list based on the key files and switches the TA mode of TEE Security World to metric mode.

[0022] Optionally, in step S14, the process of generating the metric list includes:

[0023] A disk encryption daemon is added to the REE normal world. The disk encryption daemon is used to identify the critical files of the system in the REE normal world and calculate the first metric hash value of the critical files. The first metric hash value is then sent to the TEE secure world in the form of file path, file type and first metric hash value. After the first metric hash values ​​of the critical files of all systems in the REE normal world are collected, the first metric hash value is used as the base value to generate a metric list.

[0024] Optionally, step S2 includes:

[0025] Step S21: The cryptsetup tool finds the LUKS token with read / write permissions in the control field, confirms the corresponding TEE trusted hardware from the LUKS token, and runs the TEE trusted hardware plugin corresponding to the TEE trusted hardware; the TEE trusted hardware has a hardware-level security chip that provides integrity measurement and key management functions.

[0026] Step S22: The cryptsetup tool passes the required read / write permission values ​​to the TEE-connected trusted hardware plugin;

[0027] Step S23: The TEE trusted hardware plugin obtains a read-only user key from the TPM trusted hardware: If the read-only user key is successfully obtained, proceed to steps S24 to S25; if the read-only user key is not obtained, the process ends.

[0028] Step S24: TEE Security World performs an integrity measurement on the critical file: If the measurement passes, TEE Security World derives the read-only user key from the HMAC key generated within TEE Security World to obtain the read-write user key, and then executes step S25; if the measurement fails, the read-write user key acquisition fails, and step S3 is executed.

[0029] Step S25: Obtain the LUKS token corresponding to the TEE trusted hardware plugin from step S21. The permission control layer in the TEE trusted hardware plugin compares the permission value recorded on the LUKS token with the permission value passed by the cryptsetup tool in step S22. If they match, the read / write user key derived in step S24 is returned to the cryptsetup tool. If they do not match, the TEE trusted hardware plugin refuses to pass the read / write user key to the cryptsetup tool, the read / write user key acquisition fails, and step S3 is executed.

[0030] Optionally, in step S24, TEE Security World performs integrity measurement on critical documents, including:

[0031] The disk encryption daemon in the REE normal world obtains the measurement list from the TEE secure world and performs measurement operations on key files in the measurement list to obtain a second measurement hash value. It then passes the file path of the key file and its second measurement hash value to the TEE secure world. The TEE secure world obtains the second measurement hash value and compares it with the baseline value in its measurement list. Finally, it feeds back the comparison result to the disk encryption daemon in the REE normal world.

[0032] If the second metric hash value matches the baseline value, the metric is successful, allowing key derivation operations using the HMAC key, and the TA mode is switched to monitoring mode.

[0033] If the second metric hash value is inconsistent with the baseline value, the metric fails, and key derivation operations using the HMAC key are not allowed.

[0034] Optionally, step S3 includes:

[0035] Step S31: The cryptsetup tool finds the LUKS token with read-only permissions in the control field, determines the corresponding TPM trusted hardware from the LUKS token, and runs the TPM trusted hardware plugin corresponding to the TPM trusted hardware.

[0036] Step S32: The cryptsetup tool passes the required read-only permission value to the TPM trusted hardware plugin;

[0037] Step S33: The TPM trusted hardware plugin obtains the read-only user key from the TPM trusted hardware. If the read-only user key is successfully obtained, proceed to step S34. If the read-only user key is not obtained, the process ends.

[0038] Step S34: Obtain the LUKS token corresponding to the TPM trusted hardware plugin from step S31. The permission control layer in the TPM trusted hardware plugin compares the permission value recorded on the LUKS token with the permission value transmitted by the cryptsetup tool in step S32. If they match, the read-only user key obtained in step S23 is returned to the cryptsetup tool. If they do not match, the TPM trusted hardware plugin refuses to transmit the read-only user key to the cryptsetup tool, and the read-only user key acquisition fails.

[0039] Optionally, the startup component is quantified by the TPM trusted hardware to obtain the quantification result. In steps S23 and S33, if the quantification result is successful, the read-only user key is released to the corresponding trusted hardware plugin, and the trusted hardware plugin successfully obtains the read-only user key from the TPM trusted hardware. If the quantification result is unsuccessful, the read-only user key cannot be released to the corresponding trusted hardware plugin, and the trusted hardware plugin fails to obtain the read-only user key from the TPM trusted hardware.

[0040] Optionally, the metrics that TPM trusted hardware uses to measure the boot components include:

[0041] Obtain the current PCR status, compare the current PCR status with the PCR status when sealed, and determine whether the PCR status has changed;

[0042] If the PCR status remains unchanged, it indicates that the component integrity measurement was successfully initiated, and the read-only user key was unsealed and released to the corresponding trusted hardware plugin.

[0043] If the PCR status changes, it indicates that the integrity measurement of the startup component failed and the read-only user key cannot be unsealed and released.

[0044] The PCR is a set of registers used to store the hash values ​​of the platform configuration.

[0045] Optionally, step S4 includes;

[0046] Step S41: Use IMA to monitor all files in the REE normal world and generate audit logs;

[0047] Step S42: Monitor the audit log through the disk encryption daemon and determine whether the measurement file in the audit log is a critical file based on the measurement list; if so, calculate the third measurement hash value of the measurement file and send the measurement file and its third measurement hash value to TEE Security World; if not, do not calculate the third measurement hash value of the measurement file and do not send the measurement file and its third measurement hash value to TEE Security World.

[0048] Step S43: The TEE Secure World receives the measurement file and its third measurement hash value output by the REE Ordinary World, and performs a random check verification on the measurement file according to the preset random check rules; if the measurement file is selected, the TEE Secure World calculates the fourth measurement hash value of the measurement file and verifies whether the fourth measurement hash value of the measurement file is consistent with the baseline value in the measurement list. If they are consistent, no processing is performed; if they are inconsistent, step S44 is executed; if the measurement file is not selected, the third hash value of the measurement file is verified to be consistent with the baseline value in the measurement list. If they are consistent, no processing is performed; if they are inconsistent, step S44 is executed.

[0049] Step S44: Determine whether the verification of the measurement file is a false alarm; if the verification of the measurement file is a false alarm, the LUKS encrypted disk regains read and write permissions; if the verification of the measurement file is not a false alarm, the disk encryption daemon performs permission downgrading on the LUKS encrypted disk.

[0050] Optionally, the permission can be downgraded from read-write permission to read-only permission.

[0051] In summary, this application includes at least one of the following beneficial technical effects:

[0052] This invention allows the release of user keys to unlock LUKS encrypted disks while ensuring the integrity of the boot components. However, considering the insufficient system security under this integrity state, the LUKS encrypted disk unlocked by this user key only has read-only access. Only when the integrity of critical files for the boot components and system certificate environment is ensured is the release of read-write user keys allowed, and the LUKS encrypted disk unlocked by these read-write user keys has read-write access. After the system enters the running state, the environment becomes dynamic and complex. This invention also proposes a system runtime critical file monitoring mechanism and dynamic permission adjustment combining TEE and IMA, ensuring that access permissions can be dynamically adjusted based on the integrity of critical system files during system operation. This guarantees both the security of the system environment and the security of the keys and data on the LUKS encrypted disk. Attached Figure Description

[0053] Figure 1 This is a flowchart illustrating the construction of a LUKS encrypted disk with permission control, based on a method for dynamic access control of encrypted disks according to the integrity of critical system files, as described in this application.

[0054] Figure 2 This is a flowchart illustrating the unlocking of a corresponding LUKS encrypted disk, according to an embodiment of this application, of a method for dynamic access control of encrypted disks based on the integrity of critical system files.

[0055] Figure 3 This is a flowchart illustrating the TEE security world measurement during the system operation phase of a method for dynamic access control of encrypted disks based on the integrity of critical system files, according to an embodiment of this application.

[0056] Figure 4 This is a flowchart illustrating the TEE security world and IMA-integrated system runtime critical file monitoring mechanism and dynamic permission adjustment of a method for dynamic access control of encrypted disks based on the integrity of critical system files, according to an embodiment of this application. Detailed Implementation

[0057] The present application will be further described in detail below with reference to the accompanying drawings.

[0058] This specific embodiment is merely an explanation of this application and is not intended to limit it. After reading this specification, those skilled in the art can make modifications to this embodiment without contributing any inventive step, but such modifications are protected by patent law as long as they fall within the scope of the claims of this application.

[0059] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0060] Currently, user keys for encrypted disks are typically stored in trusted hardware, which effectively protects the key file and provides convenience for unlocking encrypted devices. However, if system startup components or critical system files are tampered with, the key file can be obtained in the form of a Trojan virus, or the data in the encrypted disk can be accessed and tampered with.

[0061] More advanced solutions, such as Bitloker disk encryption tools for Windows, use TPM (Time-Based Product Management) to measure the integrity of the boot components and determine whether the TPM provides a key to unlock the device. This effectively prevents viruses from implanting in the boot components to obtain user key information. However, critical files during system operation are not measured, and if they are tampered with, there is a risk of TPM key leakage, as well as unauthorized access and tampering with the encrypted disk content. The security strength for protecting the data and keys of the encrypted disk is insufficient. Furthermore, once the system is running, the environment becomes dynamic and complex, and critical files are at risk of being tampered with at any time. Currently, there is a lack of mechanisms for dynamically detecting the integrity of critical files during system operation when protecting encrypted disks.

[0062] This invention proposes a method for dynamic access control of encrypted disks based on the integrity of critical system files. It constructs a LUKS disk encryption method with access control to restrict read and write permissions of the mapped device after the LUKS encrypted disk is unlocked. Based on the trusted hardware characteristics of TPM and TEE, and combining TPM boot measurement and sealing mechanisms, it verifies the integrity of system boot components, allowing read-only access to the LUKS encrypted disk only if the integrity is intact. Combining TEE runtime integrity verification and key decision mechanisms, it verifies the integrity of system boot components and critical system files, allowing read and write access to the LUKS encrypted disk only if the integrity is intact. IMA provides runtime critical file integrity monitoring, combined with a two-layer verification decision mechanism of TEE security world sampling verification, enabling real-time monitoring of critical file integrity during system operation. If integrity is compromised, it automatically adjusts the read and write access permissions of the LUKS encrypted disk, providing more granular and comprehensive protection for the data on the encrypted disk. This invention automatically adjusts access permissions based on integrity verification results: read and write access is provided when full verification passes; read-only access is provided when boot verification passes but runtime verification fails; and access is denied when verification fails. This invention implements complete trust chain protection from startup to runtime, ensuring system security while also ensuring business continuity through an elegant degradation mechanism.

[0063] The following is an explanation of the technical terms involved in this invention:

[0064] LUKS (Linux Unified Key Setup) is a well-known, secure, and high-performance disk encryption method that supports multiple passwords for accessing the same device. The encryption key is independent of the password, and changing the password does not require re-encrypting the data.

[0065] TPM (Trusted Platform Module) provides integrity measurement and key management functions through a hardware-level security chip. During system startup, TPM measures startup components and stores the results in the Platform Configuration Register (PCR), forming a trusted startup chain. However, TPM primarily focuses on integrity during the startup phase and has limited capabilities to protect runtime file integrity.

[0066] PCR (Platform Configuration Register): A set of registers located in the TPM (Trusted Platform Module) used to store hash values ​​of the platform configuration. These hash values ​​are accumulated through extend operations. A new value is hashed, concatenated with the current PCR value, hashed again, and the result is stored back in the PCR. It serves as a measure of system integrity from startup to the current state and is fundamental to trusted startup and remote authentication.

[0067] TEE (Trusted Execution Environment): A secure execution environment isolated from the device's main operating system (REE). It provides an isolated execution space, ensuring the confidentiality and integrity of code and data loaded into the TEE. It is used to run trusted applications (TAs) and process sensitive data.

[0068] Trusted Application (TA): An application running within the TEE. It has a high level of security and can handle sensitive information (such as keys and personal data). It interacts with ordinary applications (CA, Client Application) on the REE side through the secure API within the TEE.

[0069] REE (Rich Execution Environment): The device's main operating system environment, such as Android or Linux. It runs a wide variety of applications, but its security is lower than that of TEE. It usually coexists with TEE and communicates with TEE through a specific interface.

[0070] systemd is the core system and service manager in modern Linux systems. It is not only the first process to run after the system boots up (PID1), but it is also responsible for initializing the system, managing all other processes (services, daemons), mounting file systems, managing logs, and handling user sessions.

[0071] IMA (Integrity Measurement Architecture) is a runtime file integrity protection mechanism in the Linux kernel that performs measurements during file execution and loading. However, IMA's main functions are limited to detection and reporting, lacking deep integration with access control.

[0072] Example 1

[0073] During the system pre-configuration phase, a LUKS encrypted disk with access control is built, and read-only user keys and read-write user keys are configured. Simultaneously, TEE Security World generates a metric list containing baseline values ​​based on key files, as described in steps S11 to S14 below:

[0074] Step S11: Generate a random key through the TPM trusted hardware, use the random key as a read-only user key, and seal it through the TPM trusted hardware; in other words, the present invention seals the random key based on the binding PCR session policy and persistently stores the sealed key in the persistent storage space.

[0075] Simultaneously, the TA in the TEE secure world generates an HMAC key for persistent storage and sets the TA's mode to baseline acquisition mode. In baseline acquisition mode, the HMAC key is in a derivable state. The TA in the TEE secure world obtains the random key from the REE ordinary world and uses the HMAC key to derive the random key of the TPM. The resulting derivation key serves as the user key for reading and writing the LUKS encrypted disk.

[0076] Step S12: Encrypt the master key generated for building the LUKS encrypted disk using the configured read-only user key and read-write user key, and then store it in different key slots in the header metadata area of ​​the LUKS encrypted disk.

[0077] Specifically, building a LUKS encrypted disk generates a master key, which is the unique key for encrypting / decrypting disk data. This master key is not stored, but is encrypted by different user keys (passwords) and stored in different key slots in the header metadata area of ​​the LUKS encrypted disk. Subsequently, only the user key is needed to decrypt and obtain the master key, thereby encrypting / decrypting disk data.

[0078] Step S13: Add an access control field to the LUKS token corresponding to each key slot to record the access permissions of the keys in the key slot corresponding to the LUKS token. Among them, the read-only user key is only allowed to unlock the mapped device with read-only access, while the read-write user key is allowed to unlock the mapped device with read-write access.

[0079] like Figure 1 As shown, the header metadata area of ​​the LUKS encrypted disk retains a token area, which can generate multiple LUKS tokens. Each LUKS token has a unique serial number that corresponds one-to-one with a key slot serial number. The LUKS token records the storage information of the user key for the corresponding key slot, including trusted hardware type information and location information on the storage device. Based on the trusted hardware type information recorded in the LUKS token, the cryptsetup tool can run the corresponding trusted hardware plugin to obtain the user key protected by that trusted hardware. Using the user key, and with certain access permissions (read permission or read / write permission), the LUKS encrypted disk can be unlocked to obtain the corresponding unlocking mapping device. The mapping device is the plaintext device corresponding to the LUKS encrypted disk. Read-only mapping devices only support read-only mounting, meaning the encrypted data on the mapping device can only be read and not written, thus the disk data on the LUKS encrypted disk cannot be modified. Read / write LUKS encrypted disks support read / write mounting, meaning the encrypted data on the mapping device can be read, written, and executed, thus the disk data on the LUKS encrypted disk can be modified.

[0080] This invention adds an access control field to the LUKS token, marking the read and write permissions of the user key for the corresponding key slot (or trusted hardware), such as... Figure 1 As shown, if the trusted hardware recorded in the LUKS token is a TEE trusted hardware, the permission control field records read and write permissions; if the trusted hardware recorded in the LUKS token is a TPM trusted hardware, the permission control field records read permissions. By modifying the cryptsetup tool and related interfaces, after triggering the unlocking of the LUKS encrypted disk, the cryptsetup tool attempts to unlock the LUKS encrypted disk with the required access permissions. That is, the cryptsetup tool traverses all LUKS tokens and runs the trusted hardware plugin corresponding to the trusted hardware recorded in the LUKS token. Once the user key is successfully obtained through the trusted hardware plugin, the LUKS encrypted disk is unlocked with the required access permissions. This invention adds a permission control layer to the plugins of each trusted hardware. The permissions of the trusted hardware and the user key it protects are one-to-one. During the process of obtaining the user key through the trusted hardware plugin, the permission control layer compares the access permissions required for the LUKS encrypted disk with the permissions recorded in the permission control field of the LUKS token of that trusted hardware to see if they are consistent. If they are consistent, the user key is provided; if they are inconsistent, the user key is refused to be provided.

[0081] Step S14: TEE Security World generates a list of metrics containing benchmark values ​​based on the key files, and switches the TA mode of TEE Security World to metric mode.

[0082] The TEE Secure World connects to the REE Normal World. A disk encryption daemon is added to the REE Normal World. The disk encryption daemon is used to identify critical files in the REE Normal World system and calculate the first metric hash value of the critical files. The hash value is then transmitted to the TEE Secure World in the form of file path, file type and first metric hash value. After the first metric hash values ​​of all critical files in the REE Normal World system are collected, the first metric hash values ​​are used as the base value to generate a metric list. The metric list is stored in the secure storage of the TEE Secure World. Then the TA mode of the TEE Secure World is switched to metric mode.

[0083] It's important to know that critical files can include / sbin / init, / lib / systemd / systemd, / usr / sbin / sshd, / bin / su, / usr / bin / sudo, / bin / bash, / bin / sh, and some critical libraries (such as libc.so.6, ld-linux-x86-64.so.2, etc.).

[0084] Example 2

[0085] During system operation, the read / write user key is obtained first. If the read / write user key is successfully obtained, the LUKS encrypted disk is unlocked with read / write permissions.

[0086] like Figure 2 As shown, it includes the following steps S21 to S25.

[0087] Step S21: The crypsetup tool finds the LUKS token with read and write permissions in the control field, determines the corresponding TEE trusted hardware from the LUKS token, and runs the TEE trusted hardware plugin corresponding to the TEE trusted hardware.

[0088] Step S22: The crypsetup tool passes the required read / write permission values ​​to the TEE trusted hardware plugin;

[0089] Step S23: The TEE trusted hardware plugin obtains a read-only user key from the TPM trusted hardware:

[0090] If the TPM trusted hardware successfully measures the startup component, it releases the read-only user key to the TEE trusted hardware plugin and executes subsequent steps.

[0091] If the TPM trusted hardware fails to measure the startup component, it cannot release the read-only user key to the TEE trusted hardware plugin, and cannot proceed with subsequent steps. At this time, it is impossible to obtain either the read-write user key or the read-only user key.

[0092] Specifically, during the system startup phase (both the system reboot phase and the original system startup phase), the integrity of the startup components is measured using TPM trusted hardware. Only when the PCR state remains unchanged can the read-only user key be unsealed and released when unlocking the LUKS encrypted disk later. TPM trusted hardware has an independent root of trust, making it an ideal choice for the trust chain during the system startup phase.

[0093] It is important to know that TPM Trusted Hardware Boot measures and extends to PCR [0-7] for BIOS, UEFI firmware, and bootloader; measures and extends to PCR for kernel image and initrd [8-9]; and measures and extends to PCR for IMA policy and kernel command line parameters [10-11]. In other words, the PCR state of the PCR session policy includes the measurement values ​​of BIOS, UEFI firmware, bootloader, kernel image, initrd, IMA policy, and kernel command line parameters.

[0094] Therefore, when unlocking a LUKS encrypted disk, the TPM trusted hardware obtains the current PCR state, compares the current PCR state with the PCR state at the time of sealing, and determines whether the PCR state has changed.

[0095] If the PCR status remains unchanged, it indicates that the component integrity measurement was successful and the read-only user key was unsealed and released to the TEE trusted hardware plugin.

[0096] If the PCR status changes, it indicates that the integrity measurement of the startup component failed, and the read-only user key cannot be unsealed and released.

[0097] This invention proposes to persistently store the sealed key in the LUKS token of the LUKS encrypted disk. The conventional approach involves persistently sealing the key in TPM trusted hardware. However, due to the limited storage space of TPM trusted hardware, all LUKS encrypted disks on the system typically share a single user key. This invention, however, stores the read-only user key in the corresponding LUKS token after sealing and protection. During desealing, the sealed key in the LUKS token is read into the TPM trusted hardware, and combined with the PCR state of the TPM trusted hardware, the read-only user key is successfully obtained. This invention allows different LUKS encrypted disks to use different user keys and effectively solves the problem of limited TPM trusted hardware capacity. Furthermore, if the user key of one LUKS encrypted disk is leaked, it will not affect other LUKS encrypted disks.

[0098] Step S24: After the TEE trusted hardware plugin obtains the read-only user key, the TEE Security World performs an integrity measurement on the critical file: if the measurement passes, the TA of the TEE Security World derives the read-only user key from the HMAC key generated within the TEE Security World to obtain the read-write user key, and then executes the subsequent steps; if the measurement fails, the read-write user key acquisition fails, and an attempt is made to acquire the read-only user key (detailed in Example 3 below).

[0099] Specifically, the REE normal world system restarts, and during the initial stage of systemd service startup and system operation, the REE normal world's disk encryption daemon obtains the TEE secure world's metric list and performs metric operations on key files in the metric list to obtain a second metric hash value. The file path of the key file and its second metric hash value are then passed to the TEE secure world. The TEE secure world obtains the second metric hash value and compares it with the baseline value in its metric list. Finally, the comparison result is fed back to the REE normal world's disk encryption daemon: if the second metric hash value matches the baseline value, key derivation operations using the HMAC key are allowed, and the TA mode is switched to monitoring mode; if the second metric hash value does not match the baseline value, key derivation operations using the HMAC key are not allowed. Figure 3 As shown.

[0100] That is, during the system operation phase, the integrity of critical files is measured through the TEE security world. Only when the second measurement hash value of all critical files is consistent with the baseline value in the TEE security world, the HMAC key generated in the TEE security world can be used to derive the read-only user key when unlocking the LUKS encrypted disk, thereby obtaining the read-write user key.

[0101] In other words, the TEE security world does not directly detect the integrity of the boot components. When unlocking the LUKS encrypted disk, it is necessary to obtain the read-write user key. The encrypted disk daemon passes the read-only user key released by the TPM trusted hardware after successfully measuring the boot components to the TEE security world to derive the read-write user key for the LUKS encrypted disk. Only when the REE normal world daemon obtains the read-write user key can it unlock the LUKS encrypted disk in read and write mode. Therefore, the read-write user key can only be obtained if the integrity of the critical files of the system boot components and the system production environment is not compromised.

[0102] Step S25: Obtain the LUKS token corresponding to the TEE trusted hardware plugin from step S21. The permission control layer in the TEE trusted hardware plugin compares the permission value recorded on the LUKS token with the permission value passed by the cryptsetup tool in step S22. If they match, the read / write user key derived in step S24 is returned to the cryptsetup tool. If they do not match, the TEE trusted hardware plugin refuses to pass the read / write user key to the cryptsetup tool, and the read / write user key acquisition fails.

[0103] Example 3

[0104] As described in Example 2, in step S23, the component measurement is successfully started. However, if the key file integrity measurement or permission control verification result fails in subsequent steps S24 or S25, the read / write user key cannot be obtained. At this time, an attempt is made to obtain the read-only user key. If the read-only user key is successfully obtained, the LUKS encrypted disk is unlocked with read-only permissions.

[0105] The acquisition of the read-only user key specifically includes the following steps S31 to S34.

[0106] Step S31: The crypsetup tool finds the LUKS token with read-only permissions in the control field, identifies the corresponding TPM trusted hardware from the LUKS token, and runs the trusted hardware plugin corresponding to the TPM trusted hardware.

[0107] Step S32: The crypsetup tool passes the read-only permission value required to unlock the TPM trusted hardware plugin.

[0108] Step S33: The TPM trusted hardware plugin obtains a read-only user key from the TPM trusted hardware:

[0109] If the TPM trusted hardware successfully measures the startup component, it releases the read-only user key to the TPM trusted hardware plugin and executes subsequent steps.

[0110] If the TPM trusted hardware fails to measure the startup component, it cannot release the read-only user key to the TPM trusted hardware plugin, and cannot proceed with subsequent steps. In this case, it is impossible to obtain the read-only user key.

[0111] Specifically, during the system startup phase (both the system reboot phase and the original system startup phase), the integrity of the startup components is measured using TPM trusted hardware. Only when the PCR state remains unchanged can the read-only user key be unsealed and released when unlocking the LUKS encrypted disk later. TPM trusted hardware has an independent root of trust, making it an ideal choice for the trust chain during the system startup phase.

[0112] Therefore, when unlocking a LUKS encrypted disk, the TPM trusted hardware obtains the current PCR state, compares the current PCR state with the PCR state at the time of sealing, and determines whether the PCR state has changed.

[0113] The TPM trusted hardware obtains the current PCR status, compares the current PCR status with the PCR status when sealed, and determines whether the PCR status has changed.

[0114] If the PCR status remains unchanged, it indicates that the component integrity measurement was successfully initiated, and the read-only user key was unsealed and released to be passed to the TPM trusted hardware plugin.

[0115] If the PCR status changes, it indicates that the integrity measurement of the startup component failed, and the read-only user key cannot be unsealed and released.

[0116] Step S34: Obtain the LUKS token corresponding to the TPM trusted hardware plugin from step S31. The permission control layer in the TPM trusted hardware plugin compares the permission value recorded on the LUKS token with the permission value transmitted by the cryptsetup tool in step S32. If they match, the read-only user key obtained in step S23 is returned to the cryptsetup tool. If they do not match, the TPM trusted hardware plugin refuses to transmit the read-only user key to the cryptsetup tool, and the read-only user key acquisition fails.

[0117] Example 4

[0118] During system operation, the measurement files in the IMA are continuously monitored. When the measurement file is a critical file, if the TEE Security World finds that the integrity of the critical file has been compromised during a random inspection based on preset inspection rules, the access permissions of the LUKS encrypted disk will be automatically adjusted, specifically including the following steps S41 to S44.

[0119] Step S41: Use IMA to monitor all files in the REE normal world and generate audit logs.

[0120] Step S42: Monitor the audit logs through the disk encryption daemon and determine whether the metric file in the audit log is a critical file based on the metric list; if so, calculate the third metric hash value of the metric file and send the metric file and its third metric hash value to TEE Security World; if not, do not calculate the third metric hash value of the metric file and do not send the metric file and its third metric hash value to TEE Security World.

[0121] Specifically, after the TA mode in the TEE secure world switches to monitoring mode, IMA is used to monitor all files in the REE normal world and generate audit logs. The disk encryption daemon in the REE normal world monitors the audit logs of IMA. The REE normal world maintains the same metric list as the TEE secure world. The disk encryption daemon traverses the metric list in the REE normal world and determines whether the metric file in the audit log exists in the metric list in the REE normal world. If it exists, it means that the metric file is a critical file, and the metric file and its third metric hash value are sent to the TEE secure world. If it does not exist, it means that the metric file is not a critical file, and the metric file and its third metric hash value are not sent to the TEE secure world.

[0122] Step S43: The TEE Secure World receives the measurement file and its third measurement hash value output by the REE Ordinary World, and performs a random check verification on the measurement file according to the preset random check rules; if the measurement file is selected, the TEE Secure World calculates the fourth measurement hash value of the measurement file and verifies whether the fourth measurement hash value of the measurement file is consistent with the baseline value in the measurement list. If they are consistent, no processing is performed; if they are inconsistent, step S44 is executed; if the measurement file is not selected, the third hash value of the measurement file is verified to be consistent with the baseline value in the measurement list. If they are consistent, no processing is performed; if they are inconsistent, step S44 is executed.

[0123] Specifically, if the metric file is selected, TEE Security World will recalculate the metric file to obtain the fourth metric hash value, and verify whether the fourth metric hash value is consistent with the baseline value.

[0124] If they match, no processing is performed (corresponding to...). Figure 4 (Logic that failed to be verified in the middle).

[0125] If there is a discrepancy, the TEE secure world will notify the REE normal world's encrypted disk daemon to immediately suspend read / write permissions to unlock the LUKS encrypted disk and alert the administrator for further action (corresponding to...). Figure 4 (The logic for successful verification in the middle).

[0126] If the metric file is not selected, directly verify whether the third metric hash value of the metric file is consistent with the baseline value;

[0127] If they match, no processing is performed (corresponding to...). Figure 4 (Logic that failed to be verified in the middle).

[0128] If there is a discrepancy, the TEE secure world will notify the REE normal world's encrypted disk daemon to immediately suspend read / write permissions to unlock the LUKS encrypted disk and alert the administrator for further action (corresponding to...). Figure 4 The logic for successful verification in the middle.

[0129] It's important to know that the preset sampling rules set different verification sampling probabilities based on different file types: the sampling probability for core system components and permission management tools is 80%, the sampling probability for security-critical tools is 30%, the sampling probability for core library files is 15%, and important system tools are only re-verified when IMA fails.

[0130] Step S44: Determine whether the verification of the measurement file is a false alarm; if the verification of the measurement file is a false alarm, the LUKS encrypted disk regains read and write permissions; if the verification of the measurement file is not a false alarm, the disk encryption daemon performs permission downgrading on the LUKS encrypted disk.

[0131] Specifically, when the administrator confirms that the verification of the measurement file is a false alarm, they recalculate the fifth measurement hash value of the measurement file using tools provided by the disk encryption daemon. This fifth measurement hash value is then retransmitted to the TEE security world. The TEE security world's TA mode switches back to baseline value acquisition mode and updates the system using the fifth measurement hash value as the baseline value. After the update, the TEE security world's TA is in baseline value acquisition mode, i.e., in an HMAC key derivable state. The REE normal world's disk encryption daemon then transmits the read-only user key to the TEE security world again. The TEE security world performs HMAC key derivation on the read-only user key to generate a read-write key. The REE normal world obtains this read-write user key to restore read-write permissions to the LUKS encrypted disk. Finally, the TEE security world's TA mode switches back to monitoring mode to continue real-time monitoring of the integrity of critical system files.

[0132] It's important to know that there are two scenarios for false positives in the verification of measurement files: the first is legitimate modifications, and the second is modifications made after application updates via installation packages from trusted sources.

[0133] If the verification of the metric file is not a false alarm, the disk encryption daemon will downgrade the privileges of the LUKS encrypted disk.

[0134] Specifically, when the administrator is unable to handle the error, the disk encryption daemon downgrades the permissions of the LUKS encrypted disk. That is, because the TEE security world has a verification failure problem, it cannot obtain the read and write user key, and can only use the read-only user key protected by TPM to lock the suspended LUKS encrypted disk and then unlock the mapping with read-only permissions. After the system is restarted, since only the read-only permission key protected by TPM can be obtained, the LUKS encrypted disk can also only obtain read-only access permissions.

[0135] The present invention has the following advantages:

[0136] 1. The unlocking and mounting of LUKS encrypted disks are divided into read-only permissions and read-write permissions, which restrict access to LUKS encrypted disks and provide more granular protection, ensuring user flexibility in system use and data security.

[0137] 2. Unlocking a LUKS encrypted disk requires not only verifying the integrity of the boot components, but also verifying the integrity of critical files in the system's production environment, i.e., the runtime phase. It provides data and key protection for the LUKS encrypted disk throughout the entire system startup and runtime lifecycle, offering higher protection strength.

[0138] 3. During system operation, the integrity of critical system files is monitored, and a secondary sampling detection mechanism combining TEE Security World and IMA is provided to balance security and performance. If critical files are detected to have been tampered with and cannot be quickly repaired, the usage privileges of the LUKS encrypted disk are automatically reduced, providing more comprehensive and secure data protection for LUKS encrypted disk data.

[0139] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the foregoing disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A method for dynamic access control of encrypted disks based on the integrity of critical system files, characterized in that, include: Step S1: In the system pre-configuration phase, a LUKS encrypted disk with access control is constructed, and two types of user keys are set. At the same time, TEE Security World generates a metric list containing benchmark values ​​based on key files. The two types of user keys are read-only user keys and read-write user keys. The read-only user keys are used to unlock the LUKS encrypted disk with read-only permissions, and the read-write user keys are used to unlock the LUKS encrypted disk with read-write permissions. Step S2: During the system operation phase, prioritize obtaining the read / write user key. If successful, unlock the LUKS encrypted disk with read / write permissions and proceed to step S4. If failure occurs, proceed to step S3. Step S3: Obtain the read-only user key. If successful, unlock the LUKS encrypted disk with read-only permissions. If unsuccessful, the process ends. Step S4: Use IMA to monitor all files and generate audit logs. Filter the audit logs for critical files through the REE normal world and send them to the TEE security world after calculating the third metric hash value. The TEE security world will then check and verify the integrity of the critical files based on preset sampling rules. If the verification is inconsistent, the access permissions of the LUKS encrypted disk will be automatically downgraded from read / write permissions to read-only permissions. If the verification is consistent, the current access permissions will be maintained. The TEE secure world is used to process sensitive data and ensure the confidentiality and integrity of the code and data loaded into the TEE secure world; The security of the REE normal world is lower than that of the TEE secure world. The REE normal world and the TEE secure world coexist and communicate with the TEE secure world through a specific interface. The IMA is a system runtime file integrity protection mechanism that can perform measurements during file execution and loading.

2. The method for dynamic access control of encrypted disks based on the integrity of critical system files according to claim 1, characterized in that, Step S1 includes: Step S11: Generate a random key through the TPM trusted hardware, use the random key as the read-only user key, and seal it through the TPM trusted hardware; use the HMAC key generated by TEE Security World to derive a key from the read-only user key, and use the derived key as the read-write user key; the TPM trusted hardware has the function of providing integrity measurement and key management through hardware-level security chip. Step S12: Encrypt the master key generated for building the LUKS encrypted disk using the configured read-only user key and read-write user key, and then store it in different key slots in the header metadata area of ​​the LUKS encrypted disk; Step S13: Add an access control field to the LUKS token corresponding to each key slot to record the permissions of the keys in the key slot corresponding to the LUKS token; Step S14: TEE Security World generates a benchmark value metric list based on the key files and switches the TA mode of TEE Security World to metric mode.

3. The method for dynamic access control of encrypted disks based on the integrity of critical system files according to claim 2, characterized in that, In step S14, the process of generating the metric list includes: A disk encryption daemon is added to the REE normal world. The disk encryption daemon is used to identify the critical files of the system in the REE normal world and calculate the first metric hash value of the critical files. The first metric hash value is then sent to the TEE secure world in the form of file path, file type and first metric hash value. After the first metric hash values ​​of the critical files of all systems in the REE normal world are collected, the first metric hash value is used as the base value to generate a metric list.

4. The method for dynamic access control of encrypted disks based on the integrity of critical system files according to claim 1, characterized in that, Step S2 includes: Step S21: The cryptsetup tool finds the LUKS token with read / write permissions in the control field, confirms the corresponding TEE trusted hardware from the LUKS token, and runs the TEE trusted hardware plugin corresponding to the TEE trusted hardware; the TEE trusted hardware has a hardware-level security chip that provides integrity measurement and key management functions. Step S22: The cryptsetup tool passes the required read / write permission values ​​to the TEE-connected trusted hardware plugin; Step S23: The TEE trusted hardware plugin obtains a read-only user key from the TPM trusted hardware: If the read-only user key is successfully obtained, proceed to steps S24 to S25; if the read-only user key is not obtained, the process ends. Step S24: TEE Security World performs an integrity measurement on the critical file: If the measurement passes, TEE Security World derives the read-only user key from the HMAC key generated within TEE Security World to obtain the read-write user key, and then executes step S25; if the measurement fails, the read-write user key acquisition fails, and step S3 is executed. Step S25: Obtain the LUKS token corresponding to the TEE trusted hardware plugin from step S21. The permission control layer in the TEE trusted hardware plugin compares the permission value recorded on the LUKS token with the permission value passed by the cryptsetup tool in step S22. If they match, the read / write user key derived in step S24 is returned to the cryptsetup tool. If they do not match, the TEE trusted hardware plugin refuses to pass the read / write user key to the cryptsetup tool, the read / write user key acquisition fails, and step S3 is executed.

5. The method for dynamic access control of encrypted disks based on the integrity of critical system files according to claim 4, characterized in that, In step S24, TEE Security World performs integrity measurement on critical documents, including: The disk encryption daemon in the REE normal world obtains the measurement list from the TEE secure world and performs measurement operations on key files in the measurement list to obtain a second measurement hash value. It then passes the file path of the key file and its second measurement hash value to the TEE secure world. The TEE secure world obtains the second measurement hash value and compares it with the baseline value in its measurement list. Finally, it feeds back the comparison result to the disk encryption daemon in the REE normal world. If the second metric hash value matches the baseline value, the metric is successful, allowing key derivation operations using the HMAC key, and the TA mode is switched to monitoring mode. If the second metric hash value is inconsistent with the baseline value, the metric fails, and key derivation operations using the HMAC key are not allowed.

6. The method for dynamic access control of encrypted disks based on the integrity of critical system files according to claim 4, characterized in that, Step S3 includes: Step S31: The cryptsetup tool finds the LUKS token with read-only permissions in the control field, determines the corresponding TPM trusted hardware from the LUKS token, and runs the TPM trusted hardware plugin corresponding to the TPM trusted hardware. Step S32: The cryptsetup tool passes the required read-only permission value to the TPM trusted hardware plugin; Step S33: The TPM trusted hardware plugin obtains the read-only user key from the TPM trusted hardware. If the read-only user key is successfully obtained, proceed to step S34. If the read-only user key is not obtained, the process ends. Step S34: Obtain the LUKS token corresponding to the TPM trusted hardware plugin from step S31. The permission control layer in the TPM trusted hardware plugin compares the permission value recorded on the LUKS token with the permission value transmitted by the cryptsetup tool in step S32. If they match, the read-only user key obtained in step S23 is returned to the cryptsetup tool. If they do not match, the TPM trusted hardware plugin refuses to transmit the read-only user key to the cryptsetup tool, and the read-only user key acquisition fails.

7. The method for dynamic access control of encrypted disks based on the integrity of critical system files according to claim 6, characterized in that, The startup component is measured by the TPM trusted hardware to obtain the measurement result. In steps S23 and S33, if the measurement result is successful, the read-only user key is released to the corresponding trusted hardware plugin, and the trusted hardware plugin successfully obtains the read-only user key from the TPM trusted hardware; if the measurement result is unsuccessful, the read-only user key cannot be released to the corresponding trusted hardware plugin, and the trusted hardware plugin fails to obtain the read-only user key from the TPM trusted hardware.

8. The method for dynamic access control of encrypted disks based on the integrity of critical system files according to claim 7, characterized in that, The measurement results of TPM trusted hardware on the boot component include: Obtain the current PCR status, compare the current PCR status with the PCR status when sealed, and determine whether the PCR status has changed; If the PCR status remains unchanged, it indicates that the component integrity measurement was successfully initiated, and the read-only user key was unsealed and released to the corresponding trusted hardware plugin. If the PCR status changes, it indicates that the integrity measurement of the startup component failed and the read-only user key cannot be unsealed and released. The PCR is a set of registers used to store the hash values ​​of the platform configuration.

9. The method for dynamic access control of encrypted disks based on the integrity of critical system files according to claim 3, characterized in that, Step S4 includes; Step S41: Use IMA to monitor all files in the REE normal world and generate audit logs; Step S42: Monitor the audit logs through the disk encryption daemon and determine whether the measurement files in the audit logs are critical files based on the measurement list; If so, calculate the third metric hash value of the metric file and send the metric file and its third metric hash value to TEE Security World; If not, the third metric hash value of the metric file will not be calculated, and the metric file and its third metric hash value will not be transmitted to TEE Security World. Step S43: The TEE secure world receives the measurement file and its third measurement hash value output by the REE normal world, and performs random checks on the measurement file according to the preset random check rules; If the metric file is selected, TEE Security World calculates the fourth metric hash value of the metric file and verifies whether the fourth metric hash value of the metric file is consistent with the baseline value in the metric list. If they are consistent, no processing is performed. If they are inconsistent, step S44 is executed. If the metric file is not selected, verify whether the third hash value of the metric file is consistent with the baseline value in the metric list. If they are consistent, do not do anything. If they are inconsistent, proceed to step S44. Step S44: Determine whether the verification of the measurement file is a false alarm; if the verification of the measurement file is a false alarm, the LUKS encrypted disk regains read and write permissions; if the verification of the measurement file is not a false alarm, the disk encryption daemon performs permission downgrading on the LUKS encrypted disk.

10. The method for dynamic access control of encrypted disks based on the integrity of critical system files according to claim 9, characterized in that, The permission is downgraded from read-write permission to read-only permission.

Images