A method for controlling access to disk devices connected to an execution platform, and an execution platform for controlling access to disk devices.
By implementing a unique disk label and encryption agent to enforce access control policies, the method addresses the issue of unauthorized access in disk encryption, providing secure and robust protection against misuse and data loss.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2025-12-19
- Publication Date
- 2026-03-25
AI Technical Summary
Existing disk encryption solutions lack effective protection against misuse, as they do not provide a unique identifier for disk devices that is easy for users to interact with, and encryption at the disk level allows unauthorized access by bypassing file system checks.
A method involving a unique disk label stored in an unencrypted area of the disk device, combined with an encryption agent that enforces access control policies based on this label, ensuring only authorized applications can access the encrypted user data.
This approach provides robust protection against unauthorized access and misuse, preventing data loss and ensuring secure access to disk devices across system restarts and host systems, even in the face of ransomware attacks.
Smart Images
Figure 2026053479000001_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to a method for controlling access to a disk device connected to an execution platform and an execution platform for controlling access to a disk device.
Background Art
[0002] The Windows system does not have a unique identifier or logical unit number for a hard disk device that is easy for humans to interact with. There is a device path such as \device\00000011, but it is not unique or persistent across reboots or systems. The device path may change for the same disk during system reboot or the disk may be connected to a different system.
[0003] Each disk device has a serial number in the form of "B23BD65F", which is relatively unique to the device and persistent across reboots and multiple systems. However, it is difficult for users to remember or understand.
[0004] Disks usually have a partition table and its related information, as well as an actual volume for storing user data. The Windows system has a private system volume partition reserved by the system. Many disk encryption solutions skip the partition information and encrypt only the user volume.
[0005] Encrypted devices can be accessed in multiple ways by the system or user applications. Because encryption is at the disk device level, any application that can directly open a volume or disk can read or modify cleared data. Because storage systems are tiered, file system level checks alone cannot block these types of access. For example, the file system is at the top, followed by the volume, and then the disk. Requests starting at the file system level will typically descend to lower layers (i.e., the data will actually be read from the volume / disk), but requests starting at the volume / disk (block) level will not ascend back up to the file system. Therefore, even if a file system rule specifies "prevent this user from reading file X," if that user directly opens the disk and reads the storage area where the file resides, they completely bypass the protection in the file system by skipping that layer entirely.
[0006] Therefore, there is a need to provide a method for controlling access to disk devices connected to an execution platform that offers better protection against misuse. [Overview of the project]
[0007] The present invention is defined by independent claims 1 and 9. Further developments of the present invention are described in the dependent claims.
[0008] A method according to the present invention for controlling access to disk devices connected to an execution platform provides better protection against misuse. Other embodiments are also disclosed.
[0009] In a first aspect, the present invention relates to a method for controlling access to a disk device connected to an execution platform, - The steps of reserving an unencrypted first area of the disk device and storing a unique disk label in the first area, - The step of encrypting a second area containing user data and file information of the disk device. We propose a method that may include this.
[0010] The method further involves an encryption agent running on the execution platform, which, when a disk device is requested to be opened, - A step of reading a unique disk label stored in the first area, - Steps to obtain the protection policy for the disk device based on a unique disk label, and - Steps to handle further access to disk devices based on protection policies This may include providing an encryption agent to perform the following actions:
[0011] Considering the unique disk label stored in the first area of the disk device, it is possible to uniquely identify the disk device across system restarts, multiple host systems, and cluster nodes. Therefore, the encryption agent can obtain the protection policy corresponding to the disk device and handle further access to the disk device based on that protection policy.
[0012] The method of the present invention can address use cases for protecting disk devices from unauthorized access by processes during ransomware attacks. In particular, disk devices can be protected by using access control and encryption.
[0013] The encryption agent may be software or a software module that runs on the execution platform.
[0014] In a second aspect of the invention, the present invention provides an execution platform for controlling access to disk devices connected to the execution platform. The execution platform for controlling access to disk devices may have the same features as in the first aspect of the invention.
[0015] Needless to say, without departing from the scope of the present invention, the features described above and those to be described below can be used not only in the specified combinations but also in other combinations or individually. [Brief explanation of the drawing]
[0016] The following text describes the present invention in more detail based on exemplary embodiments with reference to the accompanying drawings, which also disclose features essential to the invention. These exemplary embodiments are for illustrative purposes only and should not be construed as limiting. For example, a description of an embodiment having a large number of elements or components should not be construed as meaning that all of these elements or components are necessary for implementation. Rather, other embodiments may include alternative elements and components, further elements or components, or additional elements or components. Unless otherwise specified, elements or components of different embodiments may be combined with each other. Modifications and changes described for one embodiment may also be applicable to other embodiments. To avoid repetition, identical or corresponding elements in different drawings are given the same reference numerals and are not described multiple times.
[0017] [Figure 1] A schematic diagram showing a disk device 7 connected to the execution platform 1. [Figure 2] A schematic diagram illustrating the functionality of encryption agent 12 for handling access to disk devices. [Figure 3] A schematic diagram illustrating the functionality of encryption agent 12 for handling access to disk devices. [Modes for carrying out the invention]
[0018] Figure 1 schematically illustrates execution platform 1 for running a software application. Execution platform 1 can be embodied, for example, as a conventional personal computer comprising a computing section 2 (e.g., including a processor 3, working memory 4, an operating system, and further hardware elements), an input unit 5 (in this case, a keyboard, for example), and an output unit 6 (e.g., a screen). Naturally, the execution platform could be, for example, a distributed system (where the components of the distributed system reside on different network-connected computers), multiple host systems, or a computer cluster.
[0019] Furthermore, a disk device 7 connected to the execution platform 1 is provided, as indicated by the double-headed arrow 8. The disk device 7 may be a hard disk drive (using magnetic storage or embodied as, for example, a solid-state drive). Furthermore, the disk device 7 may be embodied in various form factors (for example, as a 3.5-inch or 2.5-inch drive or as a USB flash drive). Specifically, the disk device 7 may be an external mass storage device or may be provided by an external mass storage device (for example, a SAN (Storage Area Network) and / or NAS (Network Attached Storage)). Thus, the disk device 7 may be a directly connected disk device, a disk in a RAID configuration (RAID = Redundant Array of Independent Disks) connected to a controller on the execution platform 1, or an external SAN / NAS storage device.
[0020] As shown, the disk device 7 comprises a first area 9 and a second area 10.
[0021] To uniquely identify the disk device 7 across reboots and / or between different execution platforms, a unique disk label 11 is associated with the disk device 7 and stored in a first area 9 on the same disk device 7. This unique disk label 11 is preferably provided by the user, so that the user can easily understand and remember it. Even if the disk device 7 is moved to another system or another execution platform, the disk device 7 can be identified by exactly the same disk label 11. By storing the unique disk label 11 in the disk device 7, independence from operating system details is provided. For example, when a normal disk is inserted into execution platform 1, it may be recognized as \Device\00000005. When that normal disk is inserted into another system, it may become \Device\00000007, or if the operating system is different, it may become something like / dev / sd1. There is no way to be sure that this is the same disk. However, according to the present invention, since a private area (first area 9) containing a user-defined unique disk label 11 (e.g., "SQL database 123") can be added to the disk device 7, no matter where the disk device 7 is moved and no matter in what order the operating system connects the disks, the user can always know that this is the same disk as they think.
[0022] The first area 9 is not encrypted and may constitute 64 MB. Further information such as key information used for encryption / decryption of the second area 10, for example, can be stored in the first area. Of course, the size of the first area 9 may be different and does not necessarily have to be 64 MB.
[0023] The second area
[0024] Furthermore, an encryption agent 12 (Fig. 2) operating on the execution platform 1 is provided. When an open request for the disk device 7 is made (Fig. 2; step S1), the encryption agent 12 can execute the following steps. The disk device 7 is identified, and a unique disk label 11 is read from the first area 9 (step S2). Thereafter, the encryption agent 12 obtains the protection policy for the disk device 7 from the data security manager 13 based on the unique disk label 11 (step S3).
[0025] Generally speaking, the protection policy will include a user set, a resource set, and a rule set. For example, "Bob" can read all files but cannot write to any file, "Alice" can read and write all files, and "Carl" can , ,
[0027] .pdf files but is only allowed to obtain the ciphertext (e.g., for backup purposes).
[0026] The data security manager 13 is not part of the execution platform 1 but is part of a remote system that can be accessed, for example, via the Internet. Therefore, since all the pieces of the puzzle are not stored on the same platform, security can be enhanced. In particular, the data security manager 13 should be considered as a separate system, a black box, that provides policy information to different execution platforms 1 on which the software of the encryption agent 12 runs. This is a centralized institution that pushes all the configuration and key information to all individual execution platforms 1.
[0027] The encryption agent 12 handles further access to the disk device 7 based on the protection policy (step S4). Step S4 involves, for example, checking the whitelist in the policy, verifying the process signature (preferably stored in the data security manager 13, so that security is brought to the execution platform that a malicious application cannot update the signature and break the protection), and enforcing the policy so that the application is permitted or denied to open the disk device 7. If opening the disk device 7 is permitted, such access includes decryption necessary to read data from the second area 10 and encryption for storing the data in the second area 10 (the policy may also indicate that the disk device 7 can be opened, but encryption or decryption is not permitted). In this way, the protection policy regarding user data is enforced and the disk device 7 is protected.
[0028] As discussed, the first region 9 is part of the disk capacity provided by the disk device 7. Therefore, a certain amount of space or several sectors are reserved on the disk device 7. These reserved sectors need to be protected from other components to prevent overwriting. Also, since these reserved sectors cannot be used by the execution platform 1, the reported device size needs to be reduced. In Windows systems, implementations above the disk layer are prone to problems and are not always reliable.
[0029] Therefore, the encryption agent 12 has an encryption disk driver 14 below the disk layer of the operating system (and thus below the disk system driver 16 of the Windows operating system), as shown in Figure 3 (upper / lower is a key characteristic as the order of processing is determined by the relative position in the stack). Thus, the encryption disk driver 14 is a kernel driver below the disk system driver 16 and can filter SCSI (SCSI = Small Computer System Interface) requests (steps S1, S11, S21). The encryption disk driver 14 also reduces the reported disk size of disk device 7 by the amount of the first area. In this example, the disk capacity of disk device 7 is 100.064 GB. Since 64 MB is reserved in the first area 9, the reported disk size is 100 GB. By providing the encryption disk driver 16, it is possible to capture the SCSI device path and process access according to the protection policy described above (steps S3, S41, S42).
[0030] In addition to these two functions, the encrypted disk driver 14 also needs to adjust the disk offset for all operations. For example, if the length of the first area 9 is 64MB, data at offset 64MB on the physical disk is actually at logical offset 0 for user data. Therefore, if a user application reads data at offset 1MB, it is necessary to add 64MB to the offset to transform the data and create a physical disk that is read at offset 65MB.
[0031] Therefore, the first area 9 is hidden, and the operating system and / or user are led to believe that the disk device 7 is slightly smaller. As a result, as already explained, the logical / effective offset will differ from the physical / actual offset, so the encryption agent 12, and in particular the encryption disk driver 14, translates any actions that refer to a specific disk offset.
[0032] The advantage of the encryption disk driver 14 being a kernel driver beneath the disk system driver 16 is that it can avoid potential bypasses. This is because one is more sensitive to the stacking order above the disk layer. Each layer (file system, volume, etc.) may have numerous drivers providing functionality at that level. However, it must also be ensured that it is the last component in the sequence, as this requires repositioning. Otherwise, a user could potentially bypass the execution platform 1 of the present invention, similar to the above example of completely bypassing the file system. For example, if the encryption disk driver 14 is a volume filter, what happens if a user performs a direct read at the disk level? The execution platform 1 of the present invention cannot see it and therefore cannot adjust, and the user could obtain incorrect data or access private areas.
[0033] Furthermore, disk device 7 may be accessed as a volume path (e.g., \\.\C:) or a raw disk device path (e.g., \\.\PhysicalDrive1), and thus through the file system layer. In this case, the encryption agent 12 includes an encryption file system driver 15 for filtering such paths (steps S1, S12, S22, and S21) and handling access according to the protection policy described above (steps S3, S41, S42, S43, and S44).
[0034] Therefore, the method of the present invention identifies and associates various paths to the encrypted disk device 7 and protects access through these paths in accordance with the corresponding protection policy.
[0035] Therefore, by protecting the disk device 7, it is possible to prevent both internal and external threats to the data. When the disk device 7 itself performs encryption / decryption, direct reading of the disk or volume from an application will result in obtaining cleared data. The method of the present invention prevents this by blocking direct reading of the disk and volume from unauthorized / whitelisted applications. Furthermore, the method of the present invention can not only be used to protect data, but also to prevent malicious applications from destroying or deleting the device. Even if an unauthorized application attempts to delete, corrupt, or update important data on the disk device 7, it will be prevented. Thus, it is possible to provide more enhanced, efficient, and robust protection for the external disk device 7.
[0036] In the case of file system-level encryption, direct reads at the disk or volume level are not a major problem because they will return encrypted data. However, ransomware may still perform direct writes to the disk or volume, which can still result in data loss. Such data loss can be very costly for a company. The method of the present invention prevents such data loss because ransomware cannot directly access disk device 7, and is not an authorized / whitelisted application.
[0037] A unique disk label 11 can be selected by the user. In particular, the user can specify a unique, human-readable name and define which applications are allowed to access disk device 7. For example, the user can sign the allowed applications (including system processes), create a process set and add process signatures, and add the process set to the protection policy. The user can compile data protection policies, access control policies, and device protection policies and associate these policies with the unique disk label 11 to provide protection. Therefore, the user does not need to remember long serial numbers, device IDs, and hardware IDs to apply policies and protections.
[0038] Furthermore, considering the unique disk label 11, it is possible to uniquely identify the disk device 7 across system restarts, multiple host systems, and cluster nodes. When the disk device 7 is moved from one system to another, the unique disk label 11 identifies the disk device 7 to be protected, enabling protection.
[0039] Furthermore, users may be able to identify whitelisted applications that can access disk device 7. Therefore, it prevents users or administrators from installing unauthorized or unverified applications to access protected data. This innovation identifies various ways to directly access / open disk device 7, ensuring that only whitelisted applications can access it. Customers can protect their disk devices from unauthorized administrators who could directly open the disk device and read or destroy data. This enhanced protection provides data security and device protection from privileged users.
[0040] According to the present invention, the first area 9 of the disk device 7 is a dedicated private storage that can only be accessed in the manner described above. Even if a user (or operating system) attempts to read from the "beginning" of the disk device 7, it is actually reading from the beginning of the second area 10. In particular, the drivers (e.g., the encrypted disk driver 14 and the encrypted file system driver 15) translate all requests to effectively hide the first area 9, leading the operating system to believe that the entire disk device 7 is solely the second area 10.
Claims
1. A method for controlling access to a disk device (7) connected to an execution platform (1), - The above method, - Reserve an unencrypted first area (9) of the disk device (7), and store a unique disk label (11) in the first area (9), - This includes encrypting the second area (10) of the disk device (7) containing user data and file information, The above method further includes an encryption agent (12) operating on the execution platform (1), which, when the opening of the disk device (7) is requested, - A step of reading the unique disk label (11) stored in the first area (9), - A step of obtaining the protection policy of the disk device (7) based on the unique disk label (11), and - Steps to handle further access to the disk device (7) based on the protection policy. A method comprising providing an encryption agent (12) that performs the following.
2. The method according to claim 1, wherein the encryption agent (12) performs decryption for reading data from the second area (10) and encryption for writing data to the second area (10).
3. The encryption agent (12) includes an encryption disk driver (14) below the disk layer of the operating system running on the execution platform (1). The method according to claim 1 or 2, wherein the encryption disk driver (14) controls access to the disk device (7) that bypasses the disk layer.
4. The method according to any one of claims 1 to 3, wherein the encryption agent (12) comprises a file system driver (15) for controlling access to the disk device (7) through the disk layer of an operating system running on the execution platform (1).
5. The aforementioned protection policy includes a whitelist of applications that are permitted to access the disk device (7), The method according to any one of claims 1 to 4, wherein the encryption agent (12) permits access to the disk device (7) only by applications included in the whitelist.
6. The method according to any one of claims 1 to 5, further comprising a data security manager for processing security policies and ensuring that the disk label (11) is a unique disk label (11).
7. The method according to any one of claims 1 to 6, comprising a label step in which a user can define the unique disk label (11).
8. The method according to any one of claims 1 to 7, comprising a policy step that allows a user to define a whitelist of applications that are permitted to access the disk device.
9. An execution platform for controlling access to connected disk devices, The disk device (7) comprises an unencrypted first area (9) that stores a unique disk label (11), and an encrypted second area that contains data and file information. When the encryption agent (12) is running on the execution platform (1) and a request is made to open the disk device (7), - A step of reading the unique disk label (11) stored in the first area (9), - A step of obtaining the protection policy of the disk device (7) based on the unique disk label (11), and - Steps to handle further access to the disk device (7) based on the protection policy. An execution platform for running this program.