Authentication program for a computer operating system

[0002] This invention relates to Microsoft® Windows® operating system file authentication. More specifically, it relates to a method of authenticating the security and integrity of files in any operating system utilizing the Microsoft® Windows® registry by altering the way in which said operating system executes application programs. Alteration is accomplished by modifying the Windows® registry.

[0003] Microsoft® Windows® is a computer operating system that allows a user to execute application programs as well as perform many other functions, such as authenticating the identity of the user, executing an application or logging the identity of a user who has accessed or modified data files.

[0004] The Windows® operating system must know what type of application to execute for each type of data file or application. The database specifying which data file type is paired with which application is called the Windows® registry. Information is stored in the registry in a tree structure, so that the operating system can easily find information related to a particular kind of file, and each such file is referred to as a class of file. Each actual piece of information is stored in an information structure called a key.

[0005] A computer virus is a small computer program that, when executed, performs actions which can be malicious, such as deleting files or causing excessive network traffic. These virus programs are written so that they can place themselves into other programs or data files and, when placed on another computer and executed, infect the new computer with the virus, perform actions, and continue to replicate from there.

[0006] The term authentication, as it is being used in the present invention, means that a file must be authenticated as being suitable to execute on a computer system before it is executed. Virus detection applications are a classic type of authentication application, but other types of authentication may include verifying the name and password of a user before the application is executed in order to enhance system security, file change detection, license auditing, activity logging, or version checking, and the like. Virus detection applications perform their actions by identifying the characteristics of viruses within application and data files and removing the virus before execution, ignoring the infection, isolating the infected file, or denying access to the file pending action from the user. The action to take in the event of virus infection is user defined.

[0007] Current methods of virus detection generally occur in one or both of the following manners. According to one method, the user schedules for automatic execution or directly executes the virus detection application (FIG. 4, 41), which scans all memory and files on a computer hard drive to detect the characteristics of known viruses (FIG. 4, 42). If a file passes the authentication process, the file is uninfected (FIG. 4, 43), and the detection application goes on to the next file (FIG. 4, 45). If the file does not pass authentication (FIG. 4, 43), the detection application performs user-defined procedures to isolate or fix the unauthenticated files (FIG. 4, 44). A second method of virus detection employs an application program which runs simultaneously with the running of the operating system, that is, they run together. In this system, when the user executes an application (FIG. 5, 51), the detection software intercepts the execution and attempts to authenticate the application (FIG. 5, 52). If the application is properly authenticated (FIG. 5, 53), the execution is allowed to proceed normally (FIG. 5, 55). If the application does not pass authentication (FIG. 5, 53), then user-defined actions are performed on the application, such as not allowing the application to be executed (FIG. 5, 54).

[0008] The first method of virus authentication is lacking because it requires a computer user to regularly execute the detection software. The second method is eqaully unapt because it requires an authentication application to be executing at all times, consuming computing resources even when not needed and potentially interfering with system performance.

[0009] The present invention overcomes the above noted limitations by altering the method in which Windows® executes application programs, causing an authentication application to perform user defined actions to verify the integrity of the application program files before application program execution can progress, acting without intervention from the user, and terminating once authentication has occurred, thus releasing computing resources back to the operating system.

[0010] The present invention is known as a Computer Authentication System, CASA, and has two primary aspects: 1) the manner in which the Microsoft® Windows® registry is modified, and 2) the method by which the changes to the Windows® registry dispatches the executed file information to one or more authentication functions. The present invention includes a standard interface, called an Application Programming Interface, API, for specifying the authentication functions which are to be performed and executed on a single, stand-alone computer in real time or from a connected remote computer system across a network. Authentication functions can include, but are not limited to, virus scanning functions such as those disclosed in Cozza\815 and Dotan\517.

[0011] The main aspect of the present invention is to minimize computer resource usage by executing authentication functions only when a user starts to execute an application program.

[0012] Other aspects of this invention will appear from the following description and appended claims, reference being made to the accompanying drawings which form a part of this specification and wherein the referenced characters correspond to the like-referenced characters in the specification.

[0013] FIG. 1 is a flowchart of prior art showing the method by which Microsoft® Windows® executes application programs.

[0014] FIGS. 2aand 2bare flowcharts showing the manner in which the present invention alters the Microsoft® Windows® method for executing application programs.

[0015] FIG. 3 is a flowchart detailing the method by which the present invention alters the Microsoft® Windows® registry.

[0016] FIG. 4 is a flowchart of prior art, detailing the method by which user executed authentication programs authenticate computer files.

[0017] FIG. 5 is a flowchart of prior art, detailing the method by which constantly running authentication applications authenticate computer files.

[0018] FIG. 6 is a C code example of a function to enable CASA authentication.

[0019] FIG. 7 is a C code example of a function to disable CASA authentication.

[0020] FIG. 8 is a C code example of a CASA authentication function.

[0021] This invention will now be described in detail by making reference to the following embodiment; however, it is to be understood that the embodiment is presented for illustration purposes only and that the invention described is not limited in its application to the details of the particular arrangement shown but, instead, is capable of wide variation and modification. Also, the terminology used herein is intended solely for the purpose of description and not by way of limitation.

[0022] In order to execute an application, the Windows® operating system searches the registry for keys related to the class of file being executed. For most applications, this class type is ‘.exe’, and this is the type that will be described in this example. The registry key for a particular file class can define directly how a file is to be handled, or redirect Windows® to another registry key for this information.

[0023] When the user attempts to execute an .exe file (FIG. 1, 11), Windows® will find information under the registry key HKEY_LOCAL_MACHINE/SOFTWARE/Classes/.exe (FIG. 1, 12). The information in this registry key may either contain information allowing Windows® to directly handle files of this class or redirect Windows® to another class key for handling information (FIG. 1, 13).

[0024] In some cases, the information in this key will contain the string ““%1” %*”, where “%1” represents the full directory path name of the application file to execute for this class of file and “%*” represents all command line options to be passed to the program. Command line arguments may include information such as the name of the data file that the application should open immediately upon executing, and/or modifying the way in which the application or data file are processed (FIG. 1, 14).

[0025] More often, the default handling information in HKEY_LOCAL_MACHINE/SOFTWARE/Classes/.exe will redirect Windows® to HKEY_LOCAL_MACHINE/SOFTWARE/Classes/exefile. In the exefile key, there are at least two sub-keys that are of concern to the present invention. 1) HKEY_LOCAL_MACHINE/SOFTWARE/Classes/exefile/DefaultIcon provides information on how to directly execute an application program without specifying a data file to open (FIG. 1, 16). This entry will contain the string “%1”, which will simply execute the application program without passing any command line arguments (FIG. 1, 17). 2) HKEY_LOCAL_MACHINE /SOFTWARE/Classes/exefile/shell/open specifies how to handle applications run from a shell, such as when a user executes an application by typing the name of the application at a DOS command prompt. This registry key will contain the string ““%1” %*”, specifying to Windows® that the application should be executed and passed any command line arguments specified by the user (FIG. 1, 18).

[0026] The installation of the CASA software modifies the Windows® registry by inspecting it for the information in the key HKEY_LOCAL_MACHINE/SOFTWARE/Classes/.exe (FIG. 3, 31). If the registry key does not redirect the operating system to the “exefile” key (FIG. 3, 32), said registry key will typically contain the information ““%1%*”. This key is modified to ““CASA”%1%*”, specifying that the CASA software should be executed, passing the name of the application to be executed, along with all program arguments (FIG. 3, 33). If the information at HKEY_LOCAL_MACHINE/SOFTWARE/Classes/.exe does redirect the operating system to the “exefile” key (FIG. 3, 32), the installation software modifies HKEY_LOCAL_MACHINE/SOFTWARE/Classes/exefile/Defaultlcon from ““%1” to ““CASA”%1” (FIG. 3, 34) and HKEY_LOCAL_MACHINE/ SOFTWARE/Classes/exefile/shell/open from ““%1%*” to ““CASA”%1%*” (FIG. 3, 35).

[0027] These modifications to the registry have the effect of changing the method in which Windows® executes a file from the method described in FIG. 1 to the method described in FIGS. 2aand 2b. When the user attempts to execute an application program (FIG. 2a, 21), Windows® inspects the contents of the HKEY_LOCAL_MACHINE/ SOFTWARE/Classes/.exe key (FIG. 2a, 22). If the key does not redirect Windows® to another key (FIG. 2a, 23), Windows® executes the CASA software, specifying the path to the application file and any command line arguments to the file (FIG. 2a, 24). If the key does redirect Windows® to the HKEY_LOCAL_MACHINE/SOFTWARE/Classes/exefile key, Windows® inspects the information in this key (FIG. 2a, 25). If the user did not execute the application from a command line (in a DOS shell) (FIG. 2a, 26), Windows® executes the CASA software, specifying only the path to the application file (FIG. 2a, 27). If the user did execute the application from a command line, Windows® executes the CASA software, specifying the path to the application file and all command line arguments to the file (FIG. 2a, 28). Upon execution, CASA performs all user defined authentication functions upon the application file before allowing the application to execute (FIG. 2a, 29). Authentication functions may include, but are not limited to, security checking, access logging, and virus scanning. If any of the user defined authentication functions fail (FIG. 2b, 210), CASA can perform a user defined action or actions, usually including some form of user notification of the failure and disallowing start of the application (FIG. 2b, 211). If all user defined authentication functions succeed (FIG. 2b, 210), CASA will execute the application with a call to the Windows® function CreateProcess (FIG. 2b, 212). The CASA software can terminate after process execution is complete, or can remain active until the created process terminates in order to perform additional user defined authentication upon application termination (FIG. 2b, 213).

[0028] Three examples of CASA behavior follow.

[0029] Since computer viruses are activated when an application containing a virus is executed, CASA may execute an antivirus scanning application to check each application program before it is executed. When used in this manner, CASA executes the antivirus application, passing it the filename of the application executed by the user. The antivirus application returns a value indicating success or failure of the scan and CASA takes appropriate action.

[0030] Additional file security can be achieved by having CASA execute a function which asks a user for a password each time a file is accessed.

[0031] Some computer viruses infect application programs by modifying the application files when executed. CASA has the ability to check for this behavior by making a copy of the application program about to be executed, executing the application while remaining active until the application program terminates, comparing the application files following termination with the copy made before execution, notifing the user if the application files have been modified in any way, restoring the modified files from the copies, and removing the copies.

[0032] The present invention improves on current methods of authentication by providing a means to perform multiple authentication functions to a single file, executing authentication functions without user intervention, and consuming computing resources only when needed.

[0033] The preferred embodiment of the present invention includes a 32-bit Windows® executable application program and supplementary applications that perform authentication functions (e.g. virus scanners, security applications, data loggers) and allow administrative users to specify the activation, deactivation, and configuration of the CASA software.

[0034] Activation and deactivation of authentication functions require modifying and restoring the values of specific keys in the Windows® registry. Configuration requires specifying to the CASA application what authentication functions are to be executed and what to do in the event of authentication failure.

[0035] The present invention has been described by reference to preferred embodiments; however, it will be appreciated that this invention is also subject to modification and to the extent that any such alterations or variations would be obvious to one of ordinary skill in this field, they are considered being within the scope of the appended claims.