KR20010113119A - Authentication method for getting the file access authority - Google Patents

Abstract

As the user executes an externally provided work response program, the relay system executes the hooking itself and authenticates the file work request transmitted from the work response program to the file system. It becomes (Hold) state. At this time, the one-reaction program is suspended for a while, the process is passed to the authentication relay system. Accordingly, the authentication relay system communicates with the authentication program of the upper layer for the authentication process in order to confirm whether the user has access to use the one reaction program. In this process, a request for authentication and a response to the request for authentication are exchanged. Based on the result of this authentication process, the authentication relay system grants access rights to the user. If the user meets the authentication requirements, the authentication relay system hands off the process to the one-responder program, allowing the one-reaction program to access the security file. Recounted.

Description

Authentication method for getting the file access authority}

The present invention relates to an authentication procedure for obtaining access rights, and more particularly, when accessing a specific file that requires security, the authentication process is performed, the access of the file is restricted when authentication fails, and the file is successful when authentication is successful. A method of enabling access of

The authentication method of the security program used in the past was mostly session-based. In other words, the session method means that accessing all files from the time of logon to the time of logoff is regarded as the same person, that is, the logged-on person. If you do this, you will be given the same permissions to log off, whether they are the same user or not. Therefore, in a situation where a user who logs on in such a session method does not log off after a user logs on, a number of security loopholes occur due to various users viewing or changing all files.

Accordingly, an object of the present invention, which is intended to solve the above-described problem, is to check whether or not to grant file access authority through an authentication process whenever a file access authority for a user is needed to reduce security loopholes. .

1 is a data transmission diagram illustrating an authentication process for the present invention to receive access to a file.

2 is a flowchart illustrating a process of setting a security file for a specific file.

3 is a flowchart showing a process of verifying a security file.

4 is a flowchart showing a process in which an authentication program receives an authentication request and processes it.

FIG. 5 is a flowchart illustrating a process of receiving file access authority by using input / output hooking for a file as a first embodiment of the present invention.

FIG. 6 is a flowchart illustrating a process of receiving file access using shell hooking as a second embodiment of the present invention.

7 is a screen example showing a security file setting window for setting a security file on a file basis.

8 is a screen example showing a security file setting window for setting a security file in a folder unit.

As the user executes an externally provided work response program, the relay system executes the hooking itself and authenticates the file work request transmitted from the work response program to the file system. It becomes (Hold) state. At this time, the one-reaction program is suspended for a while, the process is passed to the authentication relay system. Accordingly, the authentication relay system, in other words, the virtual device driver module communicates with the authentication program of the upper layer for the authentication process in order to check whether the user has access to use the one reaction program. In this process, a request for authentication and a response to the request for authentication are exchanged. Based on the result of this authentication process, the authentication relay system grants access rights to the user. If the user meets the authentication requirements, the authentication relay system hands off the process to the one-responder program, allowing the one-reaction program to access the security file. Recounted.

Next, preferred embodiments will be described in detail with reference to the accompanying drawings.

1 is a data transmission diagram illustrating an authentication process for the present invention to receive access to a file. Dividing the data transfer part into two is divided into the high level (generally called user mode) in which actual application programs are run, and the low level in which requests of such programs are processed (usually called kernel mode). Operating system) and hardware). Kernel is the most basic and core system function of the operating system. It is responsible for core tasks such as process management, CPU scheduling, interrupt handling, and storage management.

Referring to FIG. 1, when the user executes the general application program 100, the general application program requests a file access to the corresponding file (①). At this time, the authentication relay system 110 (a virtual device driver module for intercepting and performing file I / O access of a single-use program, which is usually composed of a .VXD or .SYS file format in Windows) performs input / output of a file. Check and intercept it. This is called file I / O hooking, and the authentication relay system requests the authentication program 120 to authenticate whether the user has access to the corresponding file for the intercepted file access request (②).

Here, the virtual device driver is a kind of driver that allows a program to use a hardware device or a related function, and is a special type of device driver that can directly access an operating system kernel under a Windows environment. Normally in Windows, the virtual device driver is called 'VxD' because the file name extension is '.vxd'.

The authentication program retrieves user information from user information data 121 stored in a specific folder (③), and undergoes an authentication process of whether the user has a right.

The authentication result is transmitted back to the authentication relay system 110 at a low level (④), and the authentication relay system requests file access to the file system 130 (File System) (⑤). Here, all application programs go through the file system 130 when performing file-related operations, and this process is referred to as file input / output (File I / O).

The file system 130 belonging to the low level performs a file access request and then passes the file access result back to the authentication relay system (⑥), and a message about file access or access failure for the file. To transmit to the general application (100) (⑦).

2 is a flowchart illustrating a process of setting a security file for a specific file.

A system user logs on and installs a software program that provides the present invention. The software program consists of a security program that sets up a security file and an authentication program that handles the process of authentication.

After the software program is installed, when the user executes the security program (step S200), the screen of the security file setting window of FIG. 7 or 8 is displayed. In order to prevent other users except the user from viewing the file or directory, the security file is selected for the file or folder as shown in FIG. 7 or 8 (step S210). The security file here means to specify a file that requires authentication. In addition, the security file is set to a file unit or a folder unit as shown in the screen of FIG. 7 or the screen of FIG. Save as (step S220). That is, it is stored in the form of "root.dat", for example. The information stored in this way is used when the authentication relay system (110 of FIG. 1) intercepts a file operation request and checks whether the file is a secure file. Finally, the user's information, i.e., a user name, a password, and the like are input to the users 730 of FIG. 7 or the users 830 of FIG. 8 (step S230). The input information is stored as user information data (step S240). This user information is also stored in the designated directory as the user information data file 121. This is also stored in the form of "users.dat" like the information storage of the security file path.

3 is a flowchart showing a process of verifying a security file.

When the user starts the system and logs on to execute a general application provided externally, the executable file of the general application sends a request for access to a specific file (step S300). Accordingly, the authentication relay system intercepts the access request, that is, the file access request, and checks whether the file is a security file by comparing with the path of the security file set by the security program (step S310). If the file is not a secure file, the file access request is transmitted to the file system to process the request (step S320). In the case of the security file, the authentication relay system pauses the general application program (step S330) and requests authentication from the authentication program (step S340). The authentication program receiving the authentication request performs the authentication process (step S350), and transmits the authentication result to the authentication relay system (step S360).

On the other hand, the authentication relay system determines whether to allow the file access (step S370), and if a legitimate user gives the file access permission, the one-reaction program can access the file (step S380). If the user does not have the authority, the authority to access the file is not given, and the file access request of the one reaction program is rejected (step S390).

4 is a flowchart showing a process in which an authentication program receives an authentication request and processes it. File access mode is divided into Open, Rename, Delete, Close, Read, and Write. In addition, the directory operation mode is classified into new directory creation, rename, and deletion. Instead of authenticating every file access mode, it is possible to open, in case of reading, writing, and closing, so authentication is not performed, and authentication is performed in all other access modes.

Therefore, the authentication program waits for the 'authentication required' information to receive the authentication request, when the authentication relay system sends an authentication request, the authentication program proceeds to the next. That is, the authentication relay system sends the information 'authentication required' to the authentication program, and the waiting authentication program is then performed (step S400). Then, if the authentication program provides a user information input window for requesting information to the user (step S410), the user inputs an ID and password (step S420). Accordingly, the authentication program loads user information from the user information data 121 (step S430), and compares the received information with the information obtained from the user information data 121 to determine whether the user is authorized (step S430). S440). As a result of the determination, if the user is the same person, the result of "authentication passed" is transmitted to the authentication relay system (110 of FIG. 1), and the process continues (step S450). The process does not proceed any further (step S460).

FIG. 5 is a flowchart illustrating a process of receiving file access authority by using input / output hooking for a file as a first embodiment of the present invention.

FIG. 5 is an embodiment used by ordinary users. When a user executes a general application, the general application makes a file access request (step S500), and the authentication relay system 110 of FIG. 1 intercepts this process. The security file is verified through the security file verification process of FIG. 3 (step S510). If it is not a secure file, the request is sent directly to the file system. On the contrary, in the case of the security file, the authentication relay system makes a request for authentication to the authentication program in order to proceed with the authentication process of FIG. 4 (step S520). At this time, the general application program stops the current process for a while and enters a hold state (step S530). In addition, when authentication is successful according to the authentication process (step S540) of FIG. 4, the application program resumes the current process (step S550) and transmits a file access request to the file system (step S560). . The file system receiving the access request processes this (step S570).

If authentication fails, a "file access not accessible" message is sent to the general application program (step S541).

FIG. 6 is a flowchart illustrating a process of receiving file access using shell hooking as a second embodiment of the present invention. The second embodiment can only be executed.

There are two cases of running an executable from the user's point of view. The first is when an application runs another application, and the second is when a user runs a program through an operating system (OS).

However, even in this case, the executable can only be executed through a shell (which means command handlers generally supported by the operating system, such as 4DOS or COMMAND.COM). Thus, by hooking the shell, we can see the task to run all executables. However, starting with Windows 95 or later, you can run the executable from a document. Because of this mechanism, running an executable from a document can also intercept the shell.

In this case, however, you need to do some extra work to figure out the executable associated with the document. For example, if a user double-clicks the word file "a.doc" with the extension ".doc" in Windows Explorer, the word is executed and the document is opened. In this case, you get the fact that "a.doc" opens where you are hooked. At this time, it finds out the executable program associated with "a.doc" and judges whether the executable program requires authentication, authenticates if authentication is required, and executes it if it passes the authentication (sends a value to the shell). It will not run (return without sending a value to the shell).

Based on the above description, when the user executes the executable file or the connection file, the execution of the shell is performed (step S600). Execution of the shell is performed using a shell extension (step S610). This checks whether or not the file extension is ".EXE" or ".COM" (step S620).

If the file extension is ".EXE" or ".COM", the authentication relay system hooks it and immediately checks whether it is an executable file that requires authentication (step S630). Otherwise, if the file extension is not ".EXE" or ".COM", the linked executable file is found (step S621), and the authentication relay system hooks it to check whether authentication is required. If a check is made for the authentication needs and authentication is required, the authentication process step of FIG. 4 is performed (step S640). If the user has permission or the file does not require authentication, the OS shell is executed again (step S640). If the user is not a legitimate user in the authentication step S640, the execution of the shell is stopped and the execution rejection message is displayed on the screen (step S641).

7 is a screen example showing a security file setting window for setting a security file on a file basis.

If the user wants to prevent other users from using the specific file, click the "Add" button 710 to select the file to set the security path of the security file 700 is shown on the screen. In addition, in order to release a specific security file, the security file may be released by clicking the "Remove" button 720. Then, the user clicks and sets the "Users" button 730 to designate users to give permission to view the security file.

8 is a screen example showing a security file setting window for setting a security file in a folder unit. If the user wants to prevent other users from using a particular folder, click the "Security" button 810 to select a folder to set the security path of the corresponding security folder 800 is displayed on the screen. In addition, in order to release a specific security folder, the security file may be released by clicking the "release security" button 820.

Then, the user clicks the "Users" button 830 to designate users to give permission to view the security file.

Although the present invention has been described in detail using the preferred embodiments, the scope of the present invention is not limited to the specific embodiments, and should be interpreted by the appended claims. In addition, those of ordinary skill in the art should understand that many modifications and variations are possible without departing from the scope of the present invention.

According to the present invention, by setting security for each file or folder, even if a user who is logged on to the same system, only a user who has been granted file access executes a general application that accesses a secured file, thereby further enhancing the security of the file. It works.

Claims (5)

As the user logs on to the system and executes the security program, the security program includes: a first step of providing the user with a security file setting window for allowing the user to set specific files as a security file; As the user selects a file to specify security in the security file setting window and inputs user information, the security program stores the path of the security file and the user information in a specific security path information file and a user information data file, respectively. Two steps; As a user logs on to the system and executes an externally provided application, the application relays a file work request to a file system that processes file work, and the authentication relay system intercepts the file access request of the application. A third step of reading path information of the security file from the specific security path information file; A fourth step of, after the authentication relay system confirms that the path of the security file and the path of the specific file requested for work match, requesting the authentication program for authentication of the user; As the user inputs the user information into the user information input window provided by the authentication program, the authentication program reads the user information from the user information data file and matches the user information input by the user. A fifth step of confirming and providing an authentication pass to the general program Authentication method for obtaining access rights, including. The method of claim 1, And the authentication relay system stops the process of the general application program for the authentication, and continues the process of the general application program after the authentication process is completed. The method of claim 1, The security file setting window of the second step is an authentication method for obtaining access rights, characterized in that for setting the security file in units of files and folders. The method of claim 1, The method for hooking the file access request by the authentication relay system of the third step includes file input / output hooking and shell hooking. Authentication method. The method of claim 1, The third level file access request is Open, Rename, Delete, Close, Read, Write, Create New Directory, Rename Directory, Delete Directory. Authentication method for obtaining access rights, characterized in that made.