A method for dynamic access control and encryption of files within an attribute-based security sandbox

Abstract

This invention addresses secure sandbox files and provides an attribute-based dynamic access control and encryption method. The method collects various attributes, including the current runtime environment's time, file operation path, user identity, file keywords, and file permission fields, to form an attribute set. Dynamic attributes are extracted from this attribute set, and a policy engine is used to implement dynamic access control for the file. Static attributes are extracted from the attribute set to implement attribute-based encryption, achieving dual protection for the file. This invention uses dynamic attributes, allowing administrators to modify attributes or policies to adjust file permissions on demand. Furthermore, dynamic attributes facilitate real-time assessment of the current runtime environment, enabling more flexible and secure access control. This invention reuses the access control attribute set to encrypt files, enabling the sharing of encrypted files without sharing a key.

Description

Technical Field

[0001] This invention relates to the protection of electronic documents in the field of information security, specifically to access control and encryption protection of electronic documents. Background Technology

[0002] Electronic documents refer to documents circulating internally within enterprises, governments, and other organizations. These internal documents may contain important decisions and confidential information, and their leakage can have adverse effects on the organizations in question.

[0003] Most existing electronic document protection technologies rely on manual management or forced blocking. Manual methods depend on administrators and internal policies, which incur personnel costs and are susceptible to subjective bias, making document leaks more likely. Forced blocking involves disabling potential file transfer pathways on the terminal, such as USB drives and network devices. However, this approach has significant drawbacks in today's "Internet + office" model, hindering file sharing within permitted areas and drastically reducing work efficiency.

[0004] Currently, some organizations implement Data Leakage Prevention (DLP) systems, a system architecture applied in data loss prevention scenarios. DLP classifies and assesses data risks throughout its lifecycle, while also controlling data flow. However, current DLP focuses primarily on the network side, mainly checking sensitive information carried in different network communication protocols. While it can detect data leaks during network transmission, its limitations include a relatively narrow range of leak detection pathways, and it struggles to detect leaks via Virtual Private Networks (VPNs) or encrypted traffic, necessitating a broader detection scope. Furthermore, most current endpoint DLP products only offer encryption functionality, lacking the ability to enforce control policies on the endpoint. If encryption is cracked or leaked, the risk of data leakage remains. This invention addresses the lack of control over endpoint files by combining sandboxing and file access control. An access control policy engine is placed before transparent file encryption / decryption operations, attaching conditions such as time, operation path, and user identity to each file for permission. Simultaneously, the sandbox policy effectively protects files from unauthorized reading and destruction by untrusted applications. To address the issue of key leakage in traditional encryption methods, this invention employs attribute-based encryption, which eliminates the need for users to memorize keys.

[0005] In the prior art, patent application number 202110739746.4 discloses a system and method for file redirection encryption and decryption. This application, operating in a Linux system, hooks file operation-related functions to perform encryption and decryption in memory during file reading and writing. Significant differences from this invention are: this application is applied to a Linux operating system, while this invention targets a Windows operating system, resulting in significantly different file operation APIs; this application's scope is limited to in-process file operations, while this invention possesses the ability to identify and control the content of external plaintext files; this application decrypts files in memory for each file request, while this invention uses a buffer to optimize encryption and decryption performance; this application uses traditional symmetric encryption for file encryption, while this invention uses attribute-based encryption to achieve a file encryption method that eliminates the need to remember the key and a scheme for ciphertext sharing. Summary of the Invention

[0006] This invention provides an attribute-based dynamic file access control and encryption method for file security sandboxes. Addressing the lack of policy control in file security sandbox environments, it combines dynamic access control with encryption to provide a dynamically protected file system within a secure, isolated environment. Administrators can adjust the attributes of access objects in real time, dynamically adjusting file permissions through a policy engine on the terminal. Attribute-based encryption is implemented at the kernel level, performing encryption and decryption operations seamlessly when users manipulate files, while preventing key leakage during file sharing. This aims to solve problems such as delays in the application of file control policies, difficulty in file sharing, and vulnerability to file leaks when files are accessed within an organization.

[0007] To achieve the above objectives, the present invention provides the following solution: (See attached document) Figure 1 After a user authorizes through a supported authentication method, a security sandbox is established for the user on the terminal. File operations on the user's terminal are captured, and the file's protection status is determined by whether the file operation is in the sandbox environment and by parsing the file data. If the file is unprotected, it is only isolated for protection. If the file is protected, it is sent to the access control policy engine for processing to determine whether the user has the corresponding operation permissions for the file. If the user does not have the corresponding permissions, the file operation will be intercepted and recorded. If the user has the corresponding permissions, the file is transparently encrypted and decrypted, dividing the file into read and write operations. When writing, the file is encrypted and the user's attribute information is embedded. When reading, the file is decrypted based on the user's key, and transparent access is achieved based on double buffering.

[0008] Specifically, the steps include the following:

[0009] Step S1: Perform system initialization, including generating the system master key and public key, and registering user identities;

[0010] Step S2: The user logs in using the supported authentication method on the terminal. After obtaining authorization, a secure sandbox environment is created for the user.

[0011] Supported authentication methods include: password authentication, USB-Key authentication, and certificate authentication.

[0012] Step S3: Intercept file operations in the terminal security sandbox;

[0013] Step S4: Determine whether the file corresponding to a file operation belongs to the current security sandbox;

[0014] If the file is in a security sandbox, proceed to step 6;

[0015] If the file is not in the security sandbox, proceed to step 5;

[0016] Step S5: File self-identification process. The file is parsed, and matching is performed based on the file name, file format, and file content. If a corresponding file exists in the attribute library, the file is encrypted using the attributes in the attribute library and moved into the sandbox; if no corresponding file exists, file operations are allowed.

[0017] Step S6: Collect the current runtime environment, specifically including time, file operation path, user identity information, file keywords and file permission fields, and use the access control policy engine to determine whether the file operation is allowed;

[0018] If the policy engine results in access denied, then the file operation is discarded;

[0019] If the policy engine determines that access is allowed, then file read and write operations are distinguished, and the file enters a transparent encryption / decryption process.

[0020] Step S7: Perform encryption / decryption operations according to the file operation type.

[0021] For file read operations, read the file encryption flag;

[0022] If the file is encrypted, check if a decryption cache exists. If a cache exists, return the plaintext file handle directly. If no cache exists, decrypt using the current user's attributes. If decryption is successful, return the plaintext file handle and add it to the cache.

[0023] If the file is unencrypted, the plaintext file handle is returned to the user.

[0024] For file write operations, update the plaintext in the cache and encrypt the file according to the corresponding attributes.

[0025] The beneficial effects of this invention include:

[0026] (1) Design a two-layer protection mechanism for the file.

[0027] Based on the existing secure sandbox file isolation, a dynamic access control system and kernel-level transparent encryption and decryption are introduced. Users must have both access permissions and decryption keys to access files. If either layer fails, the corresponding permissions cannot be obtained.

[0028] (2) Administrators can dynamically adjust file permissions.

[0029] Administrators can modify the attributes of access objects (environment, personnel), and can modify file access permissions in real time through the policy engine on the terminal side, instantly revoking or granting user permissions. The entire process is seamless for the user.

[0030] (3) Enhance security during encrypted file sharing.

[0031] Traditional encrypted file sharing involves key sharing. This invention eliminates the limitation of one key per file, allowing multiple users to use multiple keys to decrypt the same file, thus improving security during encrypted file sharing. Attached Figure Description

[0032] Figure 1 This is a schematic diagram of the process deployed by authorized users in the sandbox environment in the embodiment;

[0033] Figure 2 This is a schematic diagram of Windows file operation redirection in the embodiment;

[0034] Figure 3 This is a schematic diagram illustrating the similar file management strategy definition in the embodiment;

[0035] Figure 4 This is a schematic diagram illustrating the implementation of terminal-side access control in the embodiment;

[0036] Figure 5 This is a flowchart illustrating the implementation of transparent file encryption / decryption protection on the terminal side in this embodiment;

[0037] Figure 6 This is a schematic diagram of the transparent encryption method for files in the embodiment;

[0038] Figure 7 This is a schematic diagram illustrating the transparent file decryption method in the embodiment;

[0039] Figure 8 This is a flowchart of the attribute-based security sandbox dynamic access control and encryption method for files proposed in this invention. Detailed Implementation

[0040] This embodiment provides an attribute-based dynamic file access control and encryption method.

[0041] The following is an explanation of the relevant terms:

[0042] Attributes: These refer to the properties of various objects, such as file security level, system time, or user level.

[0043] File: refers to a protected file on the terminal, which has a certain degree of confidentiality and corresponding access permissions.

[0044] Security sandbox: An isolated area is defined on the terminal operating system to control the operations performed by processes located within it.

[0045] Access control: Controlling user file operations according to predefined policies, including allowing and blocking such operations.

[0046] Attribute-based encryption: Encrypts files based on user attributes and environment attributes.

[0047] The steps of this attribute-based dynamic file access control and encryption method are as follows:

[0048] S1: Perform necessary initialization of the entire system, including encryption / decryption key generation and attribute definition.

[0049] S101: The system authorization center performs key initialization, generating the system master key (MSK) and the system public key (PK).

[0050] This embodiment uses relevant functions provided in the Pairing-Based Cryptography (PBC) library for implementation, selecting a class A prime-order elliptic curve y 2 =x 3 +x, the corresponding generation parameters are shown in Table 1. The calculated system master key MSK is 128 bytes.

[0051]

[0052] Table 1. Parameters of Prime Number Order Curves for Type A

[0053] Define the complete set of attributes in the system, including user groups, file groups, and other attributes.

[0054] This embodiment provides a set of attributes:

[0055] Admin: User group, administrators;

[0056] UserGroup: User group, for regular users;

[0057] SuFile: File group, the highest-level file.

[0058] Different attributes are hashed using SHA-256 hashing, mapped to points on the group using the `element_from_hash` function, and appended to the system public key (PK). Administrators can add corresponding members to different attribute groups.

[0059] S102: Users register by providing identity information. The identity information provided to the authorization center must contain a unique ID that identifies the user. Each user provides a different value for this specific ID.

[0060] S2: Users log in using the supported authentication methods on the terminal, and a secure sandbox environment is established for users after authorization and authentication. Figure 1 This is a schematic diagram of the process.

[0061] After the user completes authorization authentication on the terminal, the server generates an authentication credential and sends it to the user's terminal. The terminal then uses this credential as the name to establish a sandbox environment. Note that at any given time, only one credential is bound to one user. This implements dynamic binding between the sandbox and the user's identity, preventing the forgery of sandboxes to gain permissions.

[0062] S3: Establishes a sandbox environment on the user terminal and achieves isolation from the host by capturing file operations.

[0063] This invention provides a method for capturing and redirecting file operations in Windows, such as... Figure 2 As shown. This embodiment provides basic capabilities for file access control and encryption / decryption protection by hooking the raw API of file operations to implement its own logic. The file operation capture method in this invention differs from directly capturing file operations through the driver; it is a user-space capture method. The process includes the following steps:

[0064] S301: DLL injection is performed when the process in the sandbox starts, and file operation APIs are inline hooked, including NtCreateFile, NtOpenFile, NtDeleteFile, NtReadFile, NtWriteFile, etc.

[0065] S302: Create a Windows service, and implement data acquisition, file encryption and access control judgments within the service. Create named pipes for different functional points to realize synchronous or asynchronous remote procedure calls.

[0066] S303: After successfully hooking the common file API, the logic to be executed is sent to the server via named pipe communication before the original operation. You can choose to wait for the remote function call to return the result synchronously, or execute the original logic asynchronously and non-blockingly.

[0067] The advantage of this method lies in extracting logic from the kernel layer and the code within the hook. This approach ensures successful DLL injection only through the driver layer, as all logic is implemented in the ring 3 layer. Furthermore, it minimizes operations within the hooked function, separating critical logic from the original process space through named pipes and system services. This significantly reduces the risk of unexpected program execution and system blue screen crashes caused by PatchGuard triggers due to problems in the hooked code.

[0068] S4: When a file operation occurs, determine if it is a file operation within the sandbox. If the file belongs to the current sandbox, proceed to step 6; otherwise, proceed to step 5.

[0069] The following scenarios are considered sandbox-based file operations:

[0070] 1) Files accessed by processes within the sandbox;

[0071] 2) The file path is located in the sandbox cache path.

[0072] S5: Identify the file and determine whether it is a protected file, such as... Figure 3 As shown.

[0073] This step enhances the file dual-layer protection mechanism of the present invention because users may engage in file operations outside the sandbox, such as file copying or downloading. Therefore, files not defined in the attribute set may exist, requiring content similarity assessment. This process includes the following steps:

[0074] S501: DLL injection is not performed on external programs in the sandbox; file operations are intercepted by filtering the driver through MiniFilter.

[0075] S502: When the PreOperation callback function is triggered, a filter is performed based on the file format, such as docx, txt and other document formats.

[0076] The file format matching method is file header feature matching.

[0077] (1) For specific file formats such as docx, png or wav, the file header data is parsed and compared with the feature library;

[0078] (2) For files without a specific format, such as txt or files with no format extension, perform encoding detection on the first 32 bytes.

[0079] The system checks whether a file belongs to a known encoding set to determine if it contains readable text information.

[0080] S503: Perform content matching. The filtering results from S302 are categorized: image format, audio format, text format, etc., and then matched against the file feature database in the system. This invention provides a programmable interface for the content matching algorithm, allowing users to provide optional file content similarity algorithms.

[0081] In particular, this invention provides a method for offline text similarity comparison using the Locality Sensitive Hash (LSH) algorithm.

[0082] (1) When creating or modifying text files in the sandbox, the files are marked as files that need protection, and the hash result is added to the hash table chain corresponding to the sandbox according to the locality sensitive hash algorithm.

[0083] (2) A preset similarity sensitivity value, which corresponds to the Hamming distance, is used in this invention as the preset value of 3. If the Hamming distance of the text is less than or equal to the preset value, it is considered that the text file being operated on is highly similar to the protected text.

[0084] If an external file is highly similar to a protected file, the external file is encrypted according to the corresponding attributes of the protected file, and given the same permissions as the protected file, allowing programs within the sandbox to access it.

[0085] S6: Collects the current runtime environment, specifically including time, file operation path, user identity information, file keywords, and file permission fields. It then uses the access control policy engine to determine whether file operations are permitted. Figure 4 As shown.

[0086] This invention introduces attribute-based access control to provide a unified description of roles and permissions, and uses the PERM metamodel for policy storage, enhancing the flexibility of the access control model. The beneficial effects of this embodiment on the present invention are that it categorizes file attributes, distinguishing between static and dynamic attributes in the attribute set, improving the flexibility of access control policies, and enabling real-time distribution and application of access control policies when the server-side policies are updated.

[0087] The process includes the following steps:

[0088] S601: Definition and distribution of attribute access control policies.

[0089] S601-1: Attribute Access Control Policy Definition. Administrators define access control policies on the server side.

[0090] First, the model is designed according to the PERM metamodel, including request definition, strategy definition, and matching rule definition. This invention categorizes file access request attributes into file attributes, environment attributes, and file operations.

[0091] File attributes include: filename, file format, and file protection attributes;

[0092] Environment attributes include: computer time, computer identifier (explained in detail in S402), user credentials, and sandbox environment status, etc.

[0093] File operations include: file read operations and file write operations.

[0094] The following is a defined access control model.

[0095] [request_definition]

[0096] r = file,env,act

[0097] [policy_definition]

[0098] p = file,env,act

[0099] [policy_effect]

[0100] e=some(where(p.eft==allow))

[0101] [matchers]

[0102] m=eval(p.file)&&eval(p.env)&&r.act==p.act

[0103] After the model is determined, the administrator needs to configure the policy according to the policy definition. The above definition provides a specific implementation policy:

[0104] p,

[0105] r.file.name=="secret.txt"&&r.file.format=="asciitext"&&r.file.protected===tru e,

[0106] r.env.box_name=="DefaultBox"&&r.env.Hour>=8&&r.env.Hour<=22&&

[0107] r.env.Day>=1&&r.env.Day<=5&&r.env.image_name=="notepad.exe"&&r.env.id=="650fe3266b5b152137e362627c581902"&&r.env.user=="eyJhbGbioiJIUzj1NiJ9…",

[0108] write

[0109] According to the policy description, when a file request occurs, the following matching will be performed:

[0110] (1) The file name is "secret.txt"

[0111] (2) The file format is asciitext

[0112] (3) The file protection bit is in a protected state.

[0113] (4) The current sandbox name is "DefaultBox"

[0114] (5) The current access time is between 8:00 and 22:00, Monday to Friday.

[0115] (6) The current requesting process is notepad.txt

[0116] (7) The current terminal identifier is "650fe3266b5b152137e362627c581902"

[0117] (8) The current user ID is "eyJhbGbioiJIUzj1NiJ9…"

[0118] (9) The current operation is a write operation.

[0119] Access is granted once a file request is successfully matched; otherwise, access is denied.

[0120] S601-2: Attribute Access Control Policy Deployment. Since this invention performs access control on the terminal side, it needs to be synchronized with the server-side access control policy in a timely manner. This invention uses ZeroMQ for policy deployment.

[0121] The server maintains the policy version number, and upgrades the version number when the administrator changes the policy.

[0122] After successful authentication, the end user proactively requests the current policy from the server. The server returns a response request, including the policy version, and compares it with the local version. If the local version number is lower than the server's, the end user requests policy synchronization from the server.

[0123] During use, end users establish a long-lived connection between the client and server using the ZMQ publish-subscribe pattern. When the server changes its policy, it broadcasts the new version number to all clients in the subscriber queue, notifying them of the change. If a client finds a discrepancy between its local and server versions, it requests policy synchronization from the server.

[0124] S602: Attribute access control implementation on the terminal side. This invention proposes a method for implementing attribute access control on the terminal side.

[0125] (1) Start the local service process, create a new named pipe "\\.\pipe\abacpipe" and listen to this named pipe to receive client access control related information.

[0126] (2) By injecting a DLL into the program running within the sandbox, file operation-related APIs are inline hooked. When a corresponding file operation occurs, the current sandbox environment parameters, file attributes, and file operation are first sent to the service process via a named pipe. When the service process receives the file request-related operation, it completes the missing environment parameters in the strategy. The following are specific methods for completing missing parameters:

[0127] Computer identifier: Determined by system hardware, it is generated by concatenating CPUID, BIOS UUID and system serial number into a string, and then hashed to record it as the computer identifier;

[0128] System time: The client and server perform NTP time synchronization to obtain the corrected system time.

[0129] (3) In the local service process, the policy engine dynamically matches according to the policy model, and returns the result as "pass" or "reject" to the client. Upon receiving the result, the client decides whether to continue executing the original system API.

[0130] It also records user actions.

[0131] S7: Perform file encryption / decryption operations based on the captured file operation type.

[0132] This step provides a transparent file encryption method for multi-user key sharing, belonging to the second layer of encryption protection in a two-layer file protection mechanism. The added benefit of this invention is that it eliminates the need to remember the file encryption key, enabling multiple users to simultaneously decrypt the ciphertext, thus improving security during file sharing. Figure 5 As shown.

[0133] Because files within a sandbox are at risk of being leaked due to malicious bypassing of the access control engine or physical access to the hard drive, file encryption is necessary. This invention addresses the problems of traditional encryption methods, such as single keys and complex ciphertext sharing methods, by proposing a transparent file encryption method with multi-user key sharing under attribute access control. The process includes the following steps:

[0134] S701: Generate user key. The user key is issued by the server after user authentication, following the same policy issuance mechanism as described in S601-2. The user key is runtime information and can be modified by the administrator in real time. User key construction method:

[0135] (1) User attribute definition. Administrators define user attributes on the server side. User attributes need to be included in the user attribute set.

[0136] (2) Generate user key. The server generates user key SK based on CP-ABE using user attributes and system master key MSK, and sends it to user terminal in real time via ZMQ.

[0137] S702: Transparent File Encryption. When write operations are permitted in the sandbox, transparent file encryption is performed. First, the file to be encrypted is moved into the plaintext buffer protected by the sandbox, and then encrypted using attribute encryption. The encrypted file is then moved back to its original path, thus achieving transparent file encryption. Figure 6 As shown.

[0138] The specific encryption method is as follows:

[0139] (1) Constructing the user access structure

[0140] The access structure is constructed based on attribute groups or single attributes defined in the system's global attribute set. It is divided into request object attributes and target object attributes. Request object attributes are user groups or specific users, while response object attributes are file groups or specific files. An example is as follows:

[0141] SuFile∩Admin

[0142] SuFile and Admin are defined in the same attribute set in S101, meaning that only access objects with both SuFile group access permissions and members of the administrator group can decrypt the file.

[0143] On the user terminal, for files that originally have an access structure, the original access structure is inherited by default during encryption; for ordinary files, the access structure is constructed by default based on a specific logged-in user, such as Bob if Bob is the currently logged-in user, the constructed access structure is Bob; for files that need to expand the access scope, an application can be made to the server, and the access structure will be issued after approval.

[0144] (2) Transparent file encryption

[0145] Start the local service process, create a new named pipe "\\.\pipe\encrypt" and listen on this named pipe to receive encrypted file paths from clients.

[0146] By injecting a DLL into the program running within the sandbox, an inline hook is performed on CloseFile. When the corresponding file operation occurs, the current file path is first sent to the service process via a named pipe. Upon receiving the file path, the service process parses the current file access structure to determine the specific access structure used for attribute encryption. After attribute encryption, the data is written to the original file path.

[0147] S703: Transparent File Decryption. When file read operations are permitted in the sandbox, transparent file decryption is performed, such as... Figure 7 As shown.

[0148] The specific decryption method is as follows:

[0149] Start the local service process, create a new named pipe "\\.\pipe\decrypt" and listen on this named pipe to receive the file path to be decrypted by the client.

[0150] By injecting a DLL into the program running within the sandbox, an inline hook is performed on OpenFile. When a corresponding file operation occurs, the current file path is first sent to the service process via a named pipe. Upon receiving the file path, the service process checks if the file exists in the file buffer. If the file exists in the buffer, it means the file has been decrypted, and a file redirection operation is performed, returning the file handle in the buffer. If the file does not exist in the buffer, it is decrypted using the current user's key. If decryption succeeds, the file is added to the buffer, and the file handle in the buffer is returned; if decryption fails, access is denied.

Claims

1. An attribute-based security sandboxed file dynamic access control and encryption method, characterized in that, The method comprises the following steps: Step S1: system initialization, including system master key and public key generation, user identity registration; Step S2: the user logs in using the supported authentication mode on the terminal, and a secure sandbox environment is established for the user after authorized authentication; The supported authentication modes include password authentication, USB-Key authentication, and certificate authentication; Step S3: intercepting file operations in the terminal secure sandbox; Step S4: judging whether a file corresponding to a file operation belongs to the current secure sandbox; If the file belongs to the secure sandbox, step 6 is performed; If the file does not belong to the secure sandbox, step 5 is performed; Step S5: file self-identification process, the file is parsed, and matching is performed based on the file name, file format, and file content; if a corresponding file exists in the attribute library, the file is encrypted through the attribute in the attribute library and is moved into the sandbox; if a corresponding file does not exist, the file operation is released; Step S6: collecting the current running environment, specifically, including time, file operation path, user identity information, file keyword, and file permission field, and determining whether the file operation is allowed through an access control strategy engine; If the strategy engine result is access denied, the file operation is discarded; If the strategy engine result is access allowed, file read / write operations are distinguished, and a transparent encryption / decryption process of the file is entered; Step S7: performing encryption / decryption operations according to the file operation type; For file read operations, read the file encryption flag bit; If it is an encrypted file, judge whether there is a decryption cache, the encrypted file is directly returned to a plaintext file handle if there is a cache, and if there is no cache, the file is decrypted using the current user attribute, and a plaintext file handle is returned and added to the cache if the decryption is successful; If it is a non-encrypted file, a user plaintext file handle is returned; For file write operations, update the plaintext in the cache, and encrypt the file according to the corresponding attribute.

Images