Transparent File Encryption

EaseFilter -The Windows File System Mini Filter Driver SDK, Your Filter Driver Solution

 
We specialize in Transparent File Encryption system filter driver development for two decades. We architect, implement and test file system filter drivers for a wide range of functionalities, EaseFilter SDK can provide you a comprehensive file security solution to implement your file access control, file audit and file encryption applications. We can offer several levels of assistance to meet your specific needs:Provide consulting service for your existing file system filter driver; Customize the SDK to meet your requirement; Create your own filter driver with our source code.
EaseFilter SDK Specification


The reference of the File System Monitor and Control Filter Driver SDK APIs, provides access to system functionality for managed application development.

EaseTag SDK Specification
The reference of the EaseTag SDK APIs,introduce the API to transparently access the stub file and manage the cloud storage.

nderstand Windows File System File I/O

Definition of: file I/O

Input/Output operations such as open, close, read, write and append, all of which deal with standard disk or tape Transparent File Encryption. The term would be used to refer to regular file operations in contrast to low-level system I/O such as dealing with virtual memory pages or OS tables of contents. Although the latter are also opened, closed, read and written, they are typically hidden from the user's view.

Overview of the Windows I/O Model

Every operating system has an implicit or explicit I/O model for handling the flow of data to and from peripheral devices. One feature of the Microsoft Windows I/O model is its support for asynchronous I/O. In addition, the I/O model has the following general features:
• The I/O manager presents a consistent interface to all kernel-mode drivers, including lowest-level, intermediate, and file system drivers. All I/O requests to drivers are sent as I/O request packets (IRPs).
• I/O operations are layered. The I/O manager exports I/O system services, which user-mode protected subsystems call to carry out I/O operations on behalf of their applications and/or end users. The I/O manager intercepts these calls, sets up one or more IRPs, and routes them through possibly layered drivers to physical devices.
• The I/O manager defines a set of standard routines, some required and others optional, that drivers can support. All drivers follow a relatively consistent implementation model, given the differences among peripheral devices and the differing functionality required of bus, function, filter, and file system drivers.
• Like the operating system itself, drivers are object-based. Drivers, their devices, and system hardware are represented as objects. The I/O manager and other operating system components export kernel-mode support routines that drivers can call to get work done by manipulating the appropriate objects.
In addition to using IRPs to convey traditional I/O requests, the I/O manager works with the PnP and power managers to send IRPs containing PnP and power requests.
I/O Request - An Overview


The following figure shows an overview of what happens when a subsystem opens a file object representing a data file on behalf of an application.

1. The subsystem calls an I/O system service to open a named file.
2. The I/O manager calls the object manager to look up the named file and to help it resolve any symbolic links for the file object. It also calls the security reference monitor to check that the subsystem has the correct access rights to open that file object.
3. If the volume is not yet mounted, the I/O manager suspends the open request temporarily and calls one or more file systems until one of them recognizes the file object as something it has stored on one of the mass-storage devices the file system uses. When the file system has mounted the volume, the I/O manager resumes the request.
4. The I/O manager allocates memory for and initializes an IRP for the open request. To drivers, an open is equivalent to a "create" request.
5. The I/O manager calls the file system driver, passing it the IRP. The file system driver accesses its I/O stack location in the IRP to determine what operation it must carry out, checks parameters, determines if the requested file is in cache, and, if not, sets up the next-lower driver's I/O stack location in the IRP.
6. Both drivers process the IRP and complete the requested I/O operation, calling kernel-mode support routines supplied by the I/O manager and by other system components (not shown in the previous figure).
7. The drivers return the IRP to the I/O manager with the I/O status block set in the IRP to indicate whether the requested operation succeeded or why it failed.
8. The I/O manager gets the I/O status from the IRP, so it can return status information through the protected subsystem to the original caller.
9. The I/O manager frees the completed IRP.
10. The I/O manager returns a handle for the file object to the subsystem if the open operation was successful. If there was an error, it returns appropriate status to the subsystem.

After a subsystem successfully opens a Transparent File Encryption object that represents a data file, a device, or a volume, the subsystem uses the returned handle to identify the file object in subsequent requests for device I/O operations (usually read, write, or device I/O control requests). To make such a request, the subsystem calls I/O system services. The I/O manager routes these requests as IRPs sent to appropriate drivers.

I/O Request - The Details

The figure illustrating opening a file object shows an IRP with two I/O stack locations, but an IRP can have any number of I/O stack locations, depending on how many layered drivers will handle a given request.

The following figure illustrates in more detail how the drivers in the Opening a File Object figure use I/O support routines (IoXxx routines) to process the IRP for a read or write request.

To get more - https://www.easefilter.com/Forums_Files/AutoFileEncryption.htm