Security System for Microcomputers

The present invention is directed to a security system for personal computers, often called microcomputers, and has specific application to the IBM line of personal microcomputers.

Microcomputers have grown in use and in number over the last decade, and are currently used by individuals, small business, medium-sized businesses, and large businesses. The use of these microcomputers runs the gamut from word processing to bookkeeping to engineering and scientific applications. Due to the ever-growing sophistication and possible applications of microcomputers, the number of them that can be expected to be in use ten years hence may quadruple that currently in use.

The microcomputer industry has not only grown by leaps and bounds, but has experienced intense competition among its many manufacturers. Standardization among the many different kinds of microcomputers is still in its early stages, but it is expected that such will ever-advance.

In the light of this intense competition, overall market growth, and the potential for such growth in the years to come, special security measures have only recently become a necessity in order to protect files from unwanted user access, and to protect access in general for only those users given such rights. Further, a security system that is practicable, useful, and safe also must be readily adaptable to all special uses and applications of microcomputers.

There are currently available microcomputer security systems that protect, in one way or another, the P.C. from unauthorized use, but these generally suffer from many disadvantages, such as lack of adequate range of security provided, lack of enough flexibility, are software-only systems that a capable programmer may easily circumvent, and lack of central control. Most prior-art security systems are simple password-type systems that simply allow or prevent access to the file or files based on the password entered, which is compared with a list of valid passwords stored in memory.

It is, therefore, the primary objective of the present invention to provide a personal comnputer security system that prevents access to the operating system of the personal computer by invalid users, and also protects against access to selected files of the computer on a user-by-user basis.

It is, also, another objective of the present invention to provide such protection by using a combination of hardware and software, with each contributing vitally to the security of the system, so that each prevents the unlawful access to the computer and files thereof.

It is yet another objective of the present invention to provide a security system for personal computers that allows for the protection of a file by degree, such that one user may have no access to that file, while another may have only read-access to that file, while still another may have both read and write-access to that file.

It is still another objective of the present invention to provide a security system for a personal computer that also selectively encrypts files by a chosen method of encryption.

It is another objective of the present invention to allow for the hardware portion of the invention to be installed such that during the bootprocessing of the system, the video-handling interrupt functon calls are monitored to prevent circumvention around the system of the present invention.

It is still an additional objective of the present invention to allow a central security administrator to make all of the choices regarding which users have access rights to the personal computer's operating system, which users have which rights to the files to be protected, and what rights each user has in deciding for himself the degree of protection and/or encryption of the files.

It is an objective of the present invention to also prevent the unwanted and unlawful formatting of the hard disc of the personal computer, as well as prevent the copying of files that the central security administrator wants to make incapable of being copied.

It is also an objective of the present invention to allow for the continual updating and changing of the security parameters on a user-by-user basis and on a file-by-file basis, so that new users may be added to the list of valid users, and also allow for the changing over of files from the status of protected and/or encrypted to not-protected and/or encrypted, and vice-versa.

Toward these and other ends, the security syustem of the present invention includes as its hardware portion an expansion board insertable into one of the expansion slots of the personal computer. The expansion board includes an EPROM on which is stored object code. There are four portions to the EPROM: the first portion contains code for boot-process handling; the second portion contains code for the main file handling interrupt function calls of the operating system; the third portion contains code for the available interrupt function calls of the present invention; and the fourth portion contains object code for the monitoring of the hard disc format interrupt vector.

The expansion board of the present invention also includes a ram chip, serving as a scratch pad, and an erasable nonvolatile memory, such as EEPROM, on which are stored the passwords of the valid users of the personal computer, the "Resource Allocation Table", which lists the files by groups and departments and which includes the system flags for setting the status of protection of each file-group and department, as well as their status with respect to each valid user. The table also includes logging information relating to an audit trail of all accesses to the operating system and protected files, of each file group with regard to encryption. The information contained in the Resource Allocation Table is accessible by the software portion of the invention via the available interrupt, the code for which is contained on the third portion of the EPROM.

The expansion board of the present invention also includes an encryption chip, the standard DES chip. This chip is initialized upon the installation of the expansion board in the expansion slot of the computer. The encryption chip is coupled to the computer system's clock by a flip-flop to divide down the frequency thereof to a workable one. Thus, when the Central Security Administrator chooses encryption for a file or for all of the files, they are automatically encrypted when written to, and automatically decrypted when read. Further, the Administrator has the option of encrypting in one method and decrypting in another so that when the file is transmitted to another computer, It cannot be read until the proper encryption methods are used.

The expansion board also includes a real-time clock chip with associated crystal for keeping an audit trail of all accesses to the computer and to the protected files. The audit trail is recorded directly onto the EEPROM. The EEPROM may also be provided with object code for its Resource Allocation Table indicating which user and/or file is to be logged by the audit trail.

The sofware portion of the security system for personal computers of the present invention includes a number of utility programs for setting the correct user and file status and system flags, as well as an AUTOEXEC.BAT file that locks the security system of the present invention with its hardware into the operating system of the computer. The first program run in this batch file, the program called SETGUARD, checks not only for a valid user password to allow or deny access to the operating system, but also checks for the existence of the board itself. This program also engages the code on the EPROM ff or hooking in the operating system's input/output calls of the file handling interrupt of the operating system.

The security system of the present invention is intended for express use with the IBM PC or IBM-compatible PC's, though its uniquness has relevance to any PC. In the IBM PC, the system of the present invention monitors the 21H interrupt, while the security system's function calls are made through the available 7CH interrupt. Further, during boot-processing, the interrupt 10H (Video Handler Interrupt) is monitored. For hard-disc-formatting protection, the system of the invention monitors the 13H interrupt.

The invention will be more readily understood with reference to the accompanying drawing, wherein

FIG. 1 is a a flow diagram showing the steps the security system of the present takes to ensure each file is accessed only by a user having some kind of right thereto;

FIG. 2 is a representation of the manner by which the files of the personal computer protected by the security system of the present invention are arranged into file groups and departments for providing a logical and flexible way of allowing protection thereof;

FIG. 3 is a chart depicting the DOS 21H function calls that the security system of the present invention monitors in an IBM PC or IBM-compatible PC;

FIG. 4 is a representation of the resource allocation table of the security system of the present invention, where the files are arranged by file-groups and departments, with the columns of the representation showing the users, and the rows the file-group and/or department of file-groups, with insertions into the squares of the table indicating the type of access rights to the file-group and/or department for each user;

FIG. 5 is a flow chart similar to FIG. 1 showing the sequence of events performed by the security system of the present invention to deny access to invalid users or users not having access to a respective file, with the additional showing in this chart of the special file called "Execute Only" file which prevents the writing or copying thereof;

FIG. 6 is a flow chart showing the chain of processes performed by the security system of the present invention in deciding whether or not a new file being created is to be encrypted or not, and the type of encryption thereof the file;

FIG. 7 is a flow chart showing the decision making process of the Central Security Administrator in deciding the type of audit trail he so desires, if one is chosen, and his options when the audit trail is full on the EEPROM on which it is stored;

FIG. 8 is a flow chart showing the chain of decisions that the security system of the present invention makes when a DOS 21H interrupt "Create a File" function call is made, such that security system of the present invention monitors such call to determine if the user and file are compatible;

FIG. 9 is a flow chart showing the chain of decisions that the security system of the present invention makes when a DOS 21H interrupt "Open a File" function call is made, such that the security system of the present invention monitors such call to determine if the user and file are compatible;

FIG. 10 is a flow chart showing the chain of decisions that the security system of the present invention makes when a DOS 21H interrupt "Close a File" function call is made, such that the security system of the present invention monitors such call to determine if the user and file are compatible;

FIG. 11 is a flow chart showing the chain of decisions that the security system of the present invention makes when a DOS 21H interrupt "Read a File" function call is made, such that the security system of the present invention monitors such call to determine if the user and file are compatible;

FIG. 12 is a flow chart showing the chain of decisions that the security system of the present invention makes when a DOS 21H interrupt "Write a File" function call is made, such that the security system of the present invention monitors such call to determine if the user and file are compatible;

FIG. 13 is a flow chart showing the chain of decisions that the security system of the present invention makes when a DOS 21H interrupt "Delete and Rename File" function call is made, such that the security system of the present invention monitors such call to determine if the user and file are compatible;

FIG. 14 is a flow chart showing the chain of decisions that the security system of the present invention makes when a DOS 21H interrupt "Execute a File" function call is made, such that the security system of the present invention monitors such call to determine if the user and file are compatible;

FIG. 15 is a flow chart showing the decision making process made by the security system of the present invention when hard-disc-formatting is attempted under the DOS 13H interrupt handler;

FIG. 16 is a schematic diagram showing the expansion board constituting the hardware portion of the security system of the present invention for insertion into an expansion slot of the personal computer to be protected;

FIG. 17 is a signal flow diagram of the circuit board of FIG. 16;

FIG. 18 is a flow chart showing the decision making processes of the security system of the present invention during boot processing, where the hardware and software components of the present invention combine to provide an unbeatable protection system; and

FIG. 19 is a decision tree for the Central Security Administrator showing the options available to him for providing constant, selected or no protection and/or encryption of newly created files and existing files.

The security system of the present invention, hereinafter called "Sentinel" for brevity's sake, is designed specifically for protecting IBM-PC and IBM-compatible microcomputers. In essence, the "Sentinel" security system of the present invention safeguards files: By allowing or preventing access to a file group or department of file groups by a user, with such access and prevention being utilized either for reading a file or group of files, for writing a file or group of files, or for both reading and writing a file or group of files, which in the present application is generally termed the "protection" of file groups: by encrypting a file or files either by the well-known DES encryption method, or another encryption method, generally termed in the present application "encryption" of a file, which includes a changeable key that may be altered by a central security administrator, so that only another microcomputer with the same key may decrypt the file or group of files previously encrypted with the same key; and by preventing access to DOS(disc operating system) of the microcomoputer if a valid password has not been entered, or an expired password has been entered.

The manner by which the system of the present invention provides control is centered around the person called a "Central Security Administrator" (CSA). He is the individual to whom is given the task of controlling access to the computer and its files by user-basis, file-basis, and department-basis. The Central Security Administrator determines which of those employees, or the like, is to have access in general, to the computer, and also determines which of the file groups and/or departments each user may read and/or write, as well as determining which or all of the files that are to be encrypted.

FIG. 1 is a control flow chart showing generally the functions available to the Central Security Administrator, as well as the flow of events for the general safeguard of files stored in memory. Assuming that the "Sentinel" security system of the present invention has already been installed in the microcomputer in a manner to be described below, all accesses to DOS files are first routed to "Sentinel" for examination to determine that the user is a valid one, and that the file is accessible to that particular user. For all file access commands, which are achieved in DOS by the 21H interrupt vector, Sentinel intercepts such commands, as indicated by block 10 in FIG. 1. It is then determined if the file which is to be accessed is protected or not. If the file is not protected, then Sentinel will either log the data and time of the attempt (Block 11) if the logging option is used, and then return to DOS, or will just return to DOS if there is no logging option used. If the file to be accessed is, in fact, a protected file, then Sentinel checks to see if the user is the Central Security Administrator or not (Block 12). If this is the Central Security Administrator, then return to DOS follows. If the user is not the Central Security Administrator, then Sentinel sees if it is a local administrator. If this is a local administrator, having broader control powers than a normal user, Sentinel will check to see if the file belongs only to the Central Security Administrator, or not. If it does belong to the Central Administrator(Block 13'), then the system will report an error message to DOS, which will deny access to that file, as indicated in block 14. If the file does not belong to the Central Security Administrator, but is one that the local administrator may gain access to, then no error message is sent to DOS, but simple return to DOS is carried out. If the user is not the local administrator, but a normal user having no overall broad control over the protection of file groups and departments, then Sentinel will check to see if this user has access rights to the file being accessed, regardless of the status of the Protection Flags, as shown in block 20. If he does not, then an error message is reported to DOS, and access is denied, as indicated in block 22. If he does have access rights, then Sentinel checks to see if this user has both read and write priveleges. This is shown in Blocks 24 and 26, where block 24 checks to see if there is an exception flag that either totally denies access to that file group or allows only reading of the file group. If there has been placed an exception flag for this file group, meaning that the local or central administrator has at least temporarily closed off write and/or read-access to this file group for the user, then Sentinel will check to see if such denial is due to the fact that the user has been denied total access(block 26). If no access at all has been set for the user, an error message(block 22) will be sent to DOS, as well as the logging thereof(block 30). If there is no exception flag, then Sentinel will check to see if the file group belongs to a department containing therein the file group. If it is "no" (block 34), an error message will be sent to DOS, since only files belonging to departments are allowed access, those not belonging to a department being special files that a particular user himself may create for his own use without access thereto by any other user. If the file does belong to a department, then Sentinel will check to see if the user has access to the overall department in which the file group is included (block 36). If he does not have access to the department, then an error message will be sent to DOS, and he will be denied access. If he does have access to the department, then Sentinel will determine if the access is a write call or a read call(block 38). If it is a read call, then Sentinel exits to DOS, and access is allowed. If it is a write call, write-access is checked for the user, and if he has such write-access, Sentinel returns to DOS and writing is allowed. If he does not have write-access, Sentinel reports an error to DOS, and access is denied.

In order to understand the grouping by which the security system of the present invention arranges the files of memory, FIG. 2 is referred to which compares the Sentinel-file arrangement to a series of cabinets 40 each containing therein a series of file groups 42. Sentinel, in the preferred embodiment, arranges file groups into a total of eight departments, such as "word processing", "budgets", "sales", and the like, as shown in FIG. 2. Each department, in turn, includes a number of file-groups, the total number of such file groups equalling sixty-four in the preferred embodiment. Each file-group itself includes a number of separate files, as indicated by open file drawer 27 in FIG. 2. The Central Security Administrator may at his choosing deny access to any one of the sixty-four file groups to any user, as well as denying access to any department. Thus, if the Central Security Administrator wanted to deny access to the department labelled "Payroll", in so doing all file groups, and, therefore, all files therein, are denied access to the user or users so desired. The manner by which the Central Administrator carries this out shall be explained below. Thus, Sentinel provides a two-tier system, whereby protection may be achieved either by individual file-groups, or by department, it being understood that if a whole department is denied access rights to a user, each file-group therein is automatically closed off,too, to that user. Which file-groups are placed under which department are at the Central Security Administrator's discretion, and it is possible to include the same file-group in more than one department. The exact type of safeguarding that the Central Security Administrator may choose for each file-group and/or department includes preventing total read and write access to the file-group and/or department, read-only access thereto without writing thereto, and, if access is allowed for a certain user, the encryption of the file in the file-group. To summarize, the Central Security Administrator may prevent access by any user of the P.C. to the files by: Preventing total read and write access to a whole department, or to any one file or files of that department, or may also prevent only write-access thereto while still allowing read-access, and, at the same time, encrypt each file whether or not a user has access to that file or not.

In order to ensure that each file that is created by a user of the P.C. is inserted into a file-group, the Central Security Administrator chooses for each user a default file-group, such a file-group 42' in FIG. 2, for, for example, user number one. Thus, whenever a user creates a file, that file is automatically placed in the default file-group 42'. However, if the user himself has not chosen a default file-group, by the SETFILE program discussed below, the new file will automatically be stored in the first file-group to which that user has write-access privilege. Also, if the Central Security Administrator(CSA) has allowed a specific user the right to choose whether or not his file or files are to be protected or not, which the Central Administrator accomplishesh by the ADMIN program discussed below, a normal user may decide himself if the file he is creating, or has already created, is to be protected or not, by using the TOGGLE program available to every normal user. This TOGGLE program allows a normal user to either protect or not-protect, as well as allow him to use the ESTATUS program to encrypt or not-encrypt, if the Central Administrator has allowed the normal user such privelege. However, the CSA also has the choice of automatically protecting and encoding each and every file for every user by the OPTIONS program, so that every file that is created is automatically encryped and/or protected, without the normal user having any power at all to alter such condition.

Before continuing with the description of the controls afforded both the CSA and normal users over the files of the P.C., it is firstly noted that security system of the present invention utilizes a novel combination of hardware and software, which combination not only provides hitherto unknown degree of safety and protection, and safeguarding of the files of the P.C. but also allows for unprecedented flexibility. The complete description of the hardware components of the invention shall be set out below in greater detail, but for now, in order to get a better understanding of unification of both hardware and software into one coherent sytem, it is noted that all memory management, file management, and I/O(input/output) calls are made in DOS through the 21H(hexadecimal) interrupt vector. There are a total of ninety-eight function call types under the 21H interrupt, with the system of the present invention monitoring and controlling twenty-two of these function calls, each of which has importance with files, file-management, and the like. FIG. 3 lists these twenty-two function calls monitored by Sentinel. Such is accomplished by the appropriate machine code formed in a first portion of an EPROM, one of the five chips used in the card of the present invention, which card is inserted into one of the expansion slots (except the J8 slot) of an IBM-PC, such being carried out at first installation of the card of the system of the present invention. It will be noted that these twenty-two function calls monitored by the system of the invention provide every access to the files of the microcomputer by which security may be compromised. As will also be explained in greater detail below, access to chip memory on the expansion board of the present invention is achieved through the 7CH interrupt vector of of the DOS operating system of the IBM-PC. The function calls, and the associated AH-register contents therefor, shall be explained below.

For the purposes of understanding the arrangement of the file groups and departments thereof, FIG. 4 shows a pictorial representation of just how the file-groups and departments would look on the EEPROM chip on the expansion board of the present invention, to be described below, such showing in FIG. 4 being called the "Resource Table Matrix". This graphic representation table 50 is divided into 20 columns, one column for each normal user whose access is to be controlled. There are 8 rows for the eight departments, and 64 rows for the 64 file-groups. This table, which may also termined the "Resource Allocation Table", is set up and controlled by the CSA. In the table, when a letter "W" is inserted in a chosen location, it means that that user has read and write access to the file-group and/or department thereof. An "R" allows him only read-access, but not write-access An "N" denies both write and read-access to the file group or department. An "L" indicates that all accesses to that file-group are logged by the logging software of the present invention to be described below. It may, therefore, be seen that the CSA may deny any type of access to a file-group or to a whole department by the simple insertion of the appropriate symbol therefor. Also, any file-group that has not been assigned to a department is automatically denied access to a user unless an appropriate access symbol has been indicated in the specific user's column for that file-group. In FIG. 4, at the department level, where there are no entires under a column, it means that access to that department is totally denied, the Resource Allocation Table limiting access to existing protected files regardless of the state of the Protection and Encryption Flags, which flags determine what happens to newly created files when they are added to the system. It may, then, be seen that tremendous flexibility is provided by the arrangement of the files by file-groups and departments according to the present invention.

In FIG. 5, there is shown a flow chart for checking a user's access rights to a given file, regardless of the state of the Protection and Encryption Flags for the case where the CSA has chosen constant protection, with the concomitant constant encryption thereof, of new files, and the constant protection of all existing files. The CSA may achieve constant protection and constant encryption by the OPTIONS program available to him, which automatically protects and encrypts all new files, or he can do so on a user-by-use basis using the ADMIN program. It is noted that if the CSA has not chosen such constant protection with or without constant encryption, each user having access rights may choose for himself whether or not such protection and/or encryption of newly created files will exist by the ESTATUS program for encryption, or the PROTECT program or TOGGLE program for protection. In FIG. 5, Sentinel checks to see if the user is the CSA, the local administrator, or a normal user, as shown in blocks 52,54, and 56. Block 58 checks to see if the file is an EXECUTE ONLY file, which comprises any executable program file, marked to deny normal reads and writes. Since normal users do not normally have write access to "execute only" files, if the user is a normal user, then access will be denied him to that file if the access is a write request, as shown in block 60. In block 62, the file-group attempted to be accessed is checked for in the Resource Allocation Table to see if the current user has any entry next to that file-group in his column. If there is no entry, then a check is made at the department level (block 64). If there is no entry, access will be denied the user. If there is an entry in the table for that user next to the file-group attempted to be accessed, then if such entry is a "no access" entry, return to DOS ensues with an error message (block 66 and block 68). If some access is allowed, write-access is checked for, as shown in Block 70, which is compared against the access attempted, as shown in blocks 72 and 74. Block 76 checks for write-access for the department level. It is again noted that, there may be access allowed at the department level, but a file-group therein may be denied access separately by the insertion of an "N" in the appropriate column of the user and row of the file-group in the Resource Allocation Table. FIG. 19 shows a decision tree for the Central Security Administrator listing the options available to him for constant protection and/or constant encryption by the OPTIONS program, which automatically protects and/or encrypts all newly created files for every user, and the files to be automatically protected and/or automatically encrypted on a user-by-user basis using the ADMIN program, and the power left to a normal user by the TOGGLE program and PROTECT program.

As mentioned above, a normal user may be given the right to decide if each new file should be encrypted or should not be encrypted. In FIG. 6, the flow chart for determining the current status of the encryption is shown. Block 80 shows the first step where the calling routine asks to see the current state of the encrypt flag. If the encrypt flag is on, then the file is marked as encrypted, as shown in block 82. If the encrypt flag is not on, then constant encryption is checked for, as shown in block 84. If it is "on", then the file is marked as encrypted, as shown in Block 82. If constant encryption is not on, which is at the discretion of CSA, then it is checked to see if automatic encryption has been set by the CSA. If automatic encryption has been set ESTATUS program by the PROTECT program of the normal user if it is available to him, then the file will be marked as encrypted and will always be encrypted until it is de-crypted by the CSA, or by the user when the CSA allows him such rights. If any type of encryption is on, then the choice of which encryption method to use is made(blocks 88 and 90). Blocks 80-90 are the logical sequence of events that determine if a file being created is to be encrypted or not encrypted, and if encrypted, which encryption method should be used. Regardless if encryption has been set or not, the file being created must be checked for to see if it is an the EXECUTE ONLY flag is on, which means that the user is attempting to copy a file marked as "Execute-Only" to a new file (which must also be marked "Execute-Only" (block 92). If it is on, then encryption must be turned off, if it has been turned on, since program files are not encrypted in the normal manner. If the destination file is a program file(block 94), then the encryption must again be turned off, if on, as shown in block 96. The last block 98, shows that regardless of the encryption, return to the calling routine is carried. FIG. 6 shows the flow of decision when a new file created and it is must be determined by the system of the present invention if such new file is to be encrypted or not.

Some of the programs available to the CSA and normal users have already been mentioned above, such as ESTATUS, PROTECT, and the like. These programs are available to the PC owner or administrator on a floppy disc accompanying the hardware, in the form of an expansion board. The programs available to the normal user are:

ESTATUS

TOGGLE

DIR1

SETFILE

PASSWORD

PROTECT

The ESTATUS AND PROTECT program files have already been mentioned above, where ESTATUS is used to change the state of auto encryption, if the CSA has given such right by not opting for constant encryption of all file-groups being created, and has not provided for automatic encryption by the ADMIN program available only to the CSA. Like the other program files on the floppy disc, ESTATUS changes the status of the condition or state on the EEPROM provided on the expansion board of the present invention, to be described below in greater detail, access thereto being carried out via the BIOS 7CH interrupt vector of DOS as mentioned above. Of course, the files on the floppy may be copied to a fixed disc, if so desired. The TOGGLE program file is used to determine if a file to be created is to be automatically protected or not. This program file may or may not be allowed for each user, such being at the option of the CSA. This program is a very simple one and merely changes the status of each file being created to be protected or not be protected. This program may also be used to protect existing, non-protected files by first copying them to a new file via DOS copy command, which will thus automatically protect them since a new file is being created. If, however, one wants to protect a number of existing files at one time, the PROTECT program-file may be used, which is also a very simple one, that merely sets the protection flags for each file, one-by-one, rather than copying them individually via DOS copy command. This PROTECT file also allows a user to place the files being protected at one time into a chosen default file-group and default department, if such default file-group and/or department are different from that chosen via the SETFILE program.

The DIR1 program is another very simple program-file that lists the current status of the files of the user by file-group and by department, along with information about their status of being encrypted or not being encrypted since every file that belongs to a file-group is by definition protected, though it may or may not be encrypted. The SETFILE program, as previously mentioned, allows a user to change the default file-group and/or default department, such meaning the place where each newly-created file is to be classified. The PASSWORD program is used by a normal user to change his or her password for gaining access to DOS, which password is known by him or her in secret, not even the CSA knowing it. Each password is stored on the EEPROM of the expansion board of the present invention.

The programs available to the CSA, over and above those available to the normal user, are:

SETKEY

ADMIN

ADREPORT

OPTIONS

LOGGING

EDNAMES

LOGDUMP

IDENT

LOGPRINT

TABLEDUMP

CSCTIME

The SETKEY program is used to enter or change the changeable key used for encryption of the files. This changeable key is used in conjunction with the internal key when using the CSC proprietary encryption method. This changeable key is a set of eight alpha-numeric characters, and is used when utilizing the CSC, proprietary, algorithm of encryption. When using the conventioal DES encryption method, only the changeable key is used, in the well-known manner.

The ADMIN program is that which allows total control by the CSS over the file-groups by user, in order to provide for access thereto and/or encryption thereof. The ADMIN program-file as shown in FIG. 4, will allocate user-access by file-group and department. All of the information that makes up the Resource Allocation Table is emplaced on the EEPROM, to which ADMIN has access via the 7CH BIOS interrupt, as explained above, for changing access rights and the like. ADMIN is also used to enable the entry of passwords, when a user is welcome, or to unenable when a user is not welcome. Also, as explained previously, this program allows for the insertion of constant protection by individual user, rather than globally for all users and can do the same for constant encryption by user and not for all users. Of course, if constant protection and/or constant encryption is "on" for the entire system, by the OPTIONS program, any entry via ADMIN shall be ignored. ADMIN can also be used to log all accesses to individual file-groups if the global, system-wide option to log has not been chosen(see LOGGING below).

The ADREPORT program-file is simply a program that will print a report listing the Resource Allocation Table of FIG. 4.

The OPTIONS program-file has been discussed previously, and allows the CSA the system-wide option of choosing constant encryption and/or constant protection, for which neither the ADMIN program nor the PROTECT program may alter. It simply sets the protection and encryption flags "on" or "off", which either ensures that all newly created files will or will not be protected and/or encrypted without any user having power to alter the states so chosen. This program will, also, allow the choice of which encryption method to use: Whether the DES standard method, or the proprietary CSC method. This program also is used to set password expiration time, such as one month hence, or the like. Finally, this program may be used to shut the system of the present invention off, so that the PC may be used with an operating system other than MS-DOS, such as P-system Pascal, or CP/M, or when DOS is not used, such as when running a flight-simulator program, or the like.

The LOGGING program-file includes a program for setting the audit trail, which keeps track of all time and dates of accesses to all files as well as all log-ons to the PC itself. There are six main logging options provided for with LOGGING program. These are: a time stamp at log-on/log-off; log-on account number, which requires an account number be entered at log-on for each user, so as to enable one to track the time spent on various activites, which may be used for client billing, or job costing, and the like; log all file accesses, which records the fact that a protected file has been opened by a valid user or an invalid attempt to access a protected file occurred; log all illegal attempts, which duplicates the logging all access option, but which may be used if not all access attempts are to be logged; logging all changes to passwords; and continuing the log when it is full, wrapping around and erasing earlier entries. If this last option were not used, when the logging file is full, further use of the PC will not be allowed until the CSA has dumped the log to a file and reset the log (this is accomplished by the LOGDUMP program to be described below). If the CSA does not want to lose any log entries, he may choose to halt the system when the log is full. It is noted that this audit trail, whatever its contents, is stored on a section of EEPROM, the same EEPROM described above for storing the passwords, flags, etc. Also, as just described, the LOGDUMP program is available to the CSA for dumping the audit trail contents of the EEPROM into a separate file therefor. This program must be used when the log-wrap-around is not chosen as an option in the LOGGING program, for otherwise the system will stay shut down. A file created on disc for the contents of the logging entries, called CSCLOG.DAT, will continually accept new data from the dumped logging entries, with the LOGDUMP program allowing erasure of previously stored logging information, or allowing the keeping thereof. This LOGDUMP program is also used to erase the contents of the audit trail on the EEPROM. FIG. 7 shows the flow of decision for logging that is open to the CSA, in deciding whether or not to use wrap-around or not, as well as using the LOGDUMP program for resetting the audit trail and for the saving thereof. Block 100 shows whether or not the log on EEPROM is full. If it is not, then normal logging procedure continues, with whatever logging options having been chosen. If the log is full, then if the wrap-around option was chosen, logging continues also for the earliest log contents are erased(FIFO). If the wrap-around was not chosen, and the half-system option was chosen, then the system shall shut down. Blocks 100,102 and 104 show the flow through the use of system-halting. Regardless if halt-system option is used, the CSA must come and dump the contents of the log to a file using the LOGDUMP program(block 106) for transference to the CSCLOG.DAT file on disc(block 108). If that file already exists, then the choice open by LOGDUMP is to save all the old trail with the newest being added(block 112), or save only the newest(block 110). If that file is not already on disc, then LOGDUMP will create that file(block 114). Regardless if the file is on disc or not, the EEPROM portion for the audit trail is reset to empty (block 116), and the logging continues(block 118).

The EDNAMES program is a very simple program that simply allows the CSA to label, or give names, to each file-group and department.

The IDENT program is used to provide protection for proprietary software against unauthorized use. In essence, each proprietary program may be given a serial number, typically of 6 alpha-numeric characters, with each serial number being placed in memory. Thus, each proprietary software includes a loop that first checks for the correct serial number, which the CSA may choose. If the correct serial number is not present in the machine, the program will not run. As mentioned above, all functions of Sentinel are achieved through the BIOS 7CH interrupt. Thus, the CSA will first enter the serial number for a particular proprietary program via the IDENT program, which he stores in memory for later validation when a user tries to use that program. As with the other 7CH functions, the contents of AH register of the central processing unit shall be set forth below, along with the inputs and outputs thereof. A serial number may also be used to identify the PC to remote devices such as a main frame. In the preferred embodiment, four such serial numbers codes may be set and used, either for protection of proprietary software, or for PC identification.

The TABLEDMP program is a program available to the CSA by which several PC's may be set up in the same way using the security system of the present invention. After a first PC has been installed with the system of the present invention with the options and audit trail chosen and set, along with the passwords, and resource allocation table, the CSA may run this program to transfer the information on EEPROM of the Sentinel card to a file on disc, which may then be transferred back to another Sentinel card installed in place of the first one, to thus duplicate it. A number of cards may be "uploaded" in this manner, so that a number of PC's, all under the control of the CSA, may be provided for multi-user access, with the appropriate protection and/or encryption of the files thereof. When uploading each new Sentinel card, that new card must then be installed without using the INSTALL program for installing the cards in the new PC, as will explained below, for, otherwise, a security breach will have been initiated.

As mentioned above, all functions of the security system of the present invention are accessed by DOS via the 7CH interrupt. Below is a table listing all of the 33 functions of "Sentinel", showing the AH register contents, along with the input and output. The AH register is the most significant byte of the AX(accumulator) register; the AL register is the least significant byte of the AX register; BL is the least significant byte of the base register(BX); BH is the most significant byte of the BX register; CH is the most significant byte of the count register(CX); DL is the least significant byte of the data register(DX), and DH is the most significant byte of the DX register; DS is the data segment register; DI is the destination index register; and SI is the source index register. All values are in hexadecimal. ##SPC1## ##SPC2##

As shown in FIG. 3, as mentioned previously, each of the 22 DOS 21H functions calls shown in monitored by "Sentinel". The function calls are further broken down according to DOS 1.00, DOS 2.00, and DOS 3.00. The column listed as "Flow Chart Reference" refers to the figure where the flow chart for that function is shown. FIG. 8 is a flow chart for the DOS function call to create a new file in conjunction with the "Sentinel" safety system (the object code for the flow of events is contained on the EPROM, to be discussed below, of the card of the present invention). Block 150 will check to see if the file already exists, as is the standard procedure. If the file exists, then it is checked to see if it is protected or not(block 152). If it is protected, and the user does not have "write-access", acess is denied (blocks 154 and 156). If the file is new, or if it is not protected, then "Sentinel" allows DOS to create the file. If it is protected but user has "write-access", then DOS will be allowed to create a file(block 158). The next blocks determine the flags to be set for the created file. Block 160 shows that Sentinel checks for automatic protection, and if the automatic flag is set for that user, then that file is marked with the current default group and default department for the user(block 166). If the automatic protection flag is not on, but the constant protection flag is on(by the OPTIONS program rather than by the ADMIN program), as shown in block 162, then the file will be marked with the current default group and default department for the user (block 164). Otherwise, no mark is set(block 165). Block 164 also indicates FIG. 6, indicating that the flow chart in that figure determines the encryption status of the file by the subroutine shown therein. If there is no protection at all for that user, then block 165 shows that the routine ends and exit to DOS follows, and does not check for encryption, since the file is not a protected one, and since regardless if it is protected or not, if the "encrypt only" flag has been set, the file will automatically be protected, while if such flag has not been set, then the file will not be encrypted (see block 80 in FIG. 6). It is noted that the "Encrypt Only" flag means that for a file with the flag therefore set to this state, the file cannot be decrypted, unless the CSA turns this flag off. After block 166, when the encryption state has been set and the default file and department have been set, block 168 checks for the "Execute Only" flag, which means that if such has been set, that file being created may not be copied. If the flag has been set, then the file is marked so(block 170), and if it has or has not been, the filename is added to the list of protected files (block 172), after which exit to DOS occurs(block 174).

FIG. 9 is a flow chart for the DOS interrupt function openign a file(DOS function call OFH and 3DH). Blocks 180 and 182 check to see if the file being opened exists or is protected. If it is no for either block, then the routine exits back to DOS. IF the file is protected, then is it a file marked "Execute Only", meaning it cannot be copied. If it is not, then write or read access is checked for (block 194). If he does not, then an error is reported to DOS. If he does, then the logging status is checked (block 198), which is followed by block 200 indicating that logging then will be carried out. If the logging flag is not on or is on, the type of call is checked, to see if it is an OFH call, which is a FCB(File Control Block) type of call(block 202). If it is, then the file will be added to the list of protected files(204). If it is not a OFH call, but is a file handling function of DOS 2.00, then the file handles and marks will be added to the list of file handles. If the file is an "Execute Only" file, (block 184), then the version of DOS is checked for. If it is not DOS 2.00, then it is DOS 3.00 and block 190 checks to see if the current user is the CSA or not. If he is not, an error message is sent to DOS (block 196). If it is, then the file is decrypted(block 192), at which point write and read access is again checked for(block 192), as before. If it is not DOS 3.00, but DOS 2.00, then block 188 checks to see if an "Execute Call" was perfomed by DOS(block 188), and if it was, then the file is decrypted. If it was not, then block 190 again checks to see if it is CSA.

FIG. 10 shows the flow chart for the "Close File Call" (DOS function call 10H and 3EH). A search is made of the open, protected files (block 226). If the file is found (block 228), then the file is closed and appropriate marks are added at the end of the file, with a concomitant removal of the file from the list of open files (blocks 228 through 234). Exit to DOS ensues(block 236).

FIG. 11 is a flow chart for the "Read File Call" (DOS function calls 14h, 21H, 27H, and 3FH). Depending upon the version of DOS, a check is made of the open protected files (blocks 240,242,244,246). If the file is not found (block 248), then exit to DOS occurs (block 262). If the file is found, then block 250 checks for encryption (block 250), which is set for that file. Write or read-access is then checked (block 252), according to the flow chart of FIG. 5, and if the user does not have access, then an error message is sent to DOS (block 254). If he does have read or write access, then read-access is allowed and the "read" is performed (block 256). Block 258 indicates the condition of encryption. If it is encrypted, then the memory is decrypted (block 260), and exit to DOS ensues. If it is not encrypted, then exit to DOS ensues without decryption.

FIG. 12 shows the flow chart for a "write-call", DOS function calls 15H, 22H, 28H, and 40H. As before, depending upon the version of DOS used, the file is searched for to see if it is an open protected file (blocks 280,282,284, and 286). If the file is not found (block 288), exit to DOS ensues(block 302). If the file is found, then block 290 determines the status of encryption and sets it. Again, write-access is checked for in block 292, and if not present, access is denied with an error message sent to DOS (block 294). If write-access does exist, then block 296 determines the state of encryption. If the file is not encrypted, then return to DOS follows. If the file is encrypted, then the memory is decrypted with the correct encryption method (block 298). The performance of the writing is then carried out (block 300), and return to DOS follows.

FIG. 13 is a flow chart for the "Delete and Rename" DOS 21H interrupt function (DOS function calls 13H, 17H, 41H, and 56H). Block 310 indicates that the file to be deleted or renamed is checked on the disc to see if it is protected. If it is not found, then simple return to DOS follows (block 320). If it is found, and it is protected, (block 314), then block 316 checks to see if write-access is allowed for the user. If not, an error message is reported to DOS (Block 318), and if the user has write-access, exit to DOS follows with the deletion or renaming of the file allowed.

FIG. 14 is a flow chart for the DOS function call "Load or Execute a Program", DOS function call 4BH (for DOS 2.00 and above). Block 340 checks to see if the file is found on disc, and protected by Sentinel. If not, return to DOS follows (block 356). If it is found and protected, then write and read-access is checked for the user (block 342), and if he does not have access rights, an error message is sent to DOS (block 344). If he does have access rights, block 346 checks to see if the file is an "Execute Only" file. If it is not, then the program name is saved in RAM on the circuit board (block 350) for later checks during the DOs open call, and then executed (block 352). Upon return, the file is re-encrypted on disc (block 354), and exit to DOS follows (block 356). If it is an "Execute Only" file (block 346), then the file is first decrypted on disc(block 348), and then named for later reencryption.

All of the 21H interrupt calls are made through the security system of the present invention, which monitors these calls, as explained above with respect to each flow chart for the particular function call. The 21H interrupt handlers for all of the function calls are included on a portion of the EPROM provided on the expansion card of the invention. The object code contained therein monitors these 21H function calls shown in FIG. 3, and performs the routines above-described and shown in the drawing. The system flags, as well as the passwords, and other system parameters that may be altered, are contained on the cards's EEPROM, with the BIOS 7CH interrupt being used by the programs of the invention on floppy disc to access them and set the parameters and information necessary for the object code programs on the EPROM. Thus, there is a united and coherent system of hardware and software tied inseparably together, where one cannot function without the other, and which provides a practically fool-proof system of security.

The security system of the present invention also provides format protection of hard discs, so that accidental or intentional formatting of hard disc is safeguarded, so that hard-earned data is not lost. Access to the disc, on a formatting basis, is done by track, sector, and disc read/write head, rather than by file-basis as in DOS interrupt 21H. Formatting is accomplished by the 13H BIOS interrupt vector, which is the lowest level of disc access available. In this 13H interrupt, when the AH register contents is 01H, the function is to reset the disk system, which is used when errors have been made therein. When the contents of the AH register is 05H, the function is to format the desired track on disc, with the ES (Extra Segment) register and the BX (base) register pointing to a format-information buffer(ES:BX). This buffer holds a series of fields of data, one for each sector on the track. Each field is four bytes long, holding track number, head number, and sector number, followed by a byte indicating how long the sector is. There is one field for each sector on the track. The security system of the present invention will monitor this BIOS 13H interrupt for the 0H and 5H function calls, in the manner shown in FIG. 15. Block 370 indicates the beginning of the routine where it is determined if the disc I/O call is for the hard disc. If it is not, then the routine returns to DOS (block 3896), since access to the hard disc is not sought. If, however, access is to the hard disc, then block 372 indicates the portion of the routine where it is checked to see if the function call is 01H (resetting of hard disc). If it is not, block 374 is the portion of the routine to check to see if the call is a 05H function call for formatting a track of the hard disc. If it is a reset call (01H) or a format call (05H) then a warning message is printed out indicating that formatting of the hard disc is about to occur, to give time to the user to make sure he is doing what he intends (block 376). If the call is not a format-a-track call, then return to DOS follows. After the warning message has been printed, the routine checks to see if the current user seeking access is the CSA or not (block 378). If he is not the CSA, then formatting of the disc is not allowed (block 384), and return to DOS follows. If he is the CSA, then the routine simpy asks (block 380) if he wants to continue, to give him a chance to reconsider, so as to prevent erasure of available data if such access is not intended. If the CSA states "no", formatting is not allowed, and return to DOS follows. If he states "yes", return to DOS follows, and the interrupt is allowed to continue with formatting of the disc, as desired.

The system of the present invention, as mentioned previously, is a combination of hardware and software. The hardware portion of the present invention is shown in FIGS. 16 and 17, and is made up of an expansion card for insertion into one of the expansion slots of the personal computer. FIG. 16 is a schematic of the component parts of the expansion card of the present invention, while FIG. 17 is a signal flow diagram. There are five main chips on the card of the present invention: EPROM 400; RAM 402; EEPROM 404; DES encryption chip 406; and clock chip 408. The EPROM 400 includes all of the machine language of the security system of the present invention for the 21H interrupt, for the 7CH interrupt, for boot handling for "kicking in" the system of the present invention, and the 13H interrupt for the formatting of hard disc. Thus, the EPROM is divided into four separate sections, each containing therein the appropriate machine language code for handling the interrupts, all of which have been described above when discussing the 21H interrupt, 7CH interrupt, and the 13 H interrupt. The boot process handler portion of the EPROM chip shall be described below in greater detail when discussing the initialization of the security system of the present invention with DOS. The five chips are all coupled together in parallel in the usual manner, as shown in FIG. 16. Transceiver 410, coupled to each chip, is a data buffer connected to the PC interface I/O channel bus, while octal tristate buffers 412 and 414 also coupled to the five chips, are address buffers for the PC interface I/O channel bus. Clock crystal 416 coupled to the clock chip 408 via a 200 Ohm resistor 418 is provided for logging purposes. This is a standard crystal, with 32.768 kHz frequency. The clock chip may be that manufactured by the National Semiconductor Co., part number MM58167AN. This clock chip with its clock crystal 416 and battery provides the time and data information for all logging options chosen by the CSA, as set forth above. The EPROM 400 is manufactured by Intel Inc., number 2764. The volatile static RAM 402 may that manufactured by Motorola, Inc. number 6116. The EEPROM 404 may be that manufactured by XICOR Inc., number 2816 or 2804. The memory reserved by the ROM and RAM of the expansion card of the invention is 32K, in the preferred embodiment. The expansion card of the present invention also includes four small rocker switches or four-position dip switch 422 which is used to initially set the memory area of the system of the present invention for the RAM and ROM thereof. In the preferred embodiment, when there is no conflict with other expansion boards in use on the PC, these switches will set the memory area for "Sentinel" at location E0000 hex, location D8000 hex, or E8000 hex. There are sixteen possible choices of 32K memory areas from which to choose (address 80000 to F8000), some of which are used by various other expansion boards and ROM's. The three memory areas above-enumerated are those that are not usually used. The dip switch 422 is coupled to a 4-bit comparator 424 for enabling the board, which is coupled to the PC I/O channel bus by lines A13 through A16 thereof of the IBM PC 62-pin I/O channel bus. Address de-coder or de-multiplexer 426(LS139) is provided in the conventional manner. Flip-flop 428 (LS74) is also provided and connected to the "clock" line, in the usual manner, for dividing the system clock pulses down to a usable frequency for the DES chip 406. The DES chip 406 is one that is made by the Western Digital Corp., number WD2001. It includes the standard DES (Data Encryption Standard) code.

FIG. 17 shows the signal flow of events. Address buffer 410, connected to the five chips alobg address bus 450, is also connected through the decoder 426. Data bus 412, 414 is connected to the chips via data bus 452. Flip-flop 428 is coupled to the system clock via line 454 and to the DES chip, while the reset therefor is via line 456.

To install the "Sentinel" security system of the present invention, a diskette is provided that includes the following files:

AUTOEXEC.BAT

SENTINEL.BAT

SETGUARD.EXE

INSTALL.EXE

FMTON.EXE

FMTOFF.EXT

DESINS.EXT

The AUTOEXEC.BAT is a batch file for bringing up the system in the way desired, so that the security system of the present invention is initialized and "hooked" into the system, so that the use of the P.C. is not possible without first going through the system of the present invention. This batch file has as its first line the command: SETGUARD, which is the software security portion of the present invention, which, therefore, executes the SETGUARD program to automatically initialize the security system of the present invention. FIG. 18 is a flow diagram showing the logical steps followed in booting up the PC with Sentinel installed. Block 500 indicates that during the initial booting process, BIOS (Basic Input/Output System) searches for ROM from addresses COOOOh to EOOOOh, in the usual manner (assuming the IBM PC does not have the BIOS ROM, prevalent in versions before March, 1983) and finds the code on the EPROM 400 of the "Sentinel" expansion card, and executes the code (block 502). The code on the EPROM will initiate the software interrupt 7Ch for the "Sentinel" function calls utilizing this interrupt (block 504). " Sentinel" then further checks to see if it is on or not, and if it is not, return to BIOS ensues (blocks 506 and 508). The CSA has the choice of the turning security system off under the OPTIONS program described above, which program is available only to the CSA, so that when certain IBM programs are run that tend to conflict with "Sentinel", such conflict would be avoided. If the security system is "on", then code is engaged to monitor BIOS calls, using BIOS interrupt 10H (the video handler interrupt), thus preventing access to DOS before the monitoring thereof by the security system of the present invention. Such BIOS 10H interrupt monitoring effectively prevents circumventing the securiy system of the invention by denying access. If such monitoring did not exist, then in the time it takes to execute the SETGUARD program a user may be able to gain access to DOS by another route (block 510). Blocks 512,514, and 516 indicate the normal flow of events during the BIOS/DOS boot process handling, followed by the running of AUTOEXEC.BAT, which calls SETGUARD.COM (Block 18). Block 520 indicates that BIOS interrupt 10H checks to see that SETGUARD.COM has, in fact, been called and executed, and, if it has not been, then an error message is printed out(block 522). If the SETGUARD.COM has been executed, it checks to see if the code on the EPROM 400 on the circuit board has been run(block 514). If it has not (as, for example. when using the old BIOS ROM) it checks to see if the board is present (block 526). If the board is not present, then access is denied and an error message printed out, since an illegal attempt to access has been performed. If the code on the EPROM has been executed - for the "new" ROMS- then SETGUARD.COM carries out its steps, as indicated in blocks 528, which asks for user password, and checks to see if it is valid or not. Thereafter, the system date and time is set, and the code on the EPROM 400 for monitoring DOS interrupt 21H is engaged (block 530). Blocks 532 and 534 show whether or not there is a program to run or not. Block 536 indicates exit to DOS, with the remainder of AUTOEXEC.BAT allowed to run.

For the CSA to install the "Sentinel" security system of the invention, the INSTALL program on the installation disc is run, which completely resets the information contained on the EEPROM, erasing the passwords, resource allocation table information, and logging information thereon. Thus, "Sentinel" is prepared to start from the beginning, for the recording the information set by the CSA for his own needs. The installation disc also includes the password program, so that AUTOEXEC. BAT will automatically run the PASSWORD program after installation. The CSA must then enter his code, such as 22 (when there are only 20 normal user, and one CSA, and one local administrator). Thereafter, the CSA will put in his password, so that slot 22 will thereafter be associated with the password entered in that slot, thus denying access to that slot, and its associated controls, unless the correct password has been entered. Thereafter, the installation disc will automatically run the CSCTIME program, described previously, for setting the time and date. The DESINST.EXT is then run, if the DES option has been chosen, for setting that encryption code. If another encryption code has been selected, then the CSA simply ignores this program, and presses the necessary keys to end the batch file. This installation diskette is used only at the time of installation; during normal usage of the PC with "Sentinel" installed, the simple boot diskette is used, which includes the AUTOEXEC.BAT file, with the SETGUARD.EXE. program thereon, along with the other various programs described previously. For normal users, another diskette is prepared, in which is included the programs to which they have access.

While a specific embodiment of the invention has been shown and described, it is to be understood that numerous changes and modifications may be made therein without departing from the scope and spirit of the invention, as set out in the appended claims. For example, with owners of personal computers utilizing fixed disc storage, most or all of the files on the diskette of the invention which includes all of the programs for controlling the security of the P.C. may be stored on the fixed disc, including the AUTO.EXEC and SETGUARD programs.