IES60970B2 - Data protection apparatus for a computer workstation - Google Patents

Description

DATA PROTECTION APPARATUS FOR A COMPUTER WORKSTATION This invention relates to a data protection apparatus for a computer workstation.

Although the invention is applicable to standalone workstations and to other forms of data storage media, it is especially applicable to the protection of data on the hard discs of networked personal computers (PCs) which are available for general use, as in college laboratories and shared computing facilities in industry.

In these environments, the operability of each machine, including its ability to access the network, depends critically on the system and network software installed on the hard disc. This software is vulnerable to deletion by careless or inappropriate use and is liable to corruption by software viruses. As a result, the system may become inoperable or may spread software viruses from its system software to unsuspecting users and through them to other machines. In addition, it is difficult to control use of the machines for purposes other than those for which they were intended, as a user 25 can take complete control by booting up a machine from a floppy disc, which may contain games and programs infected by software viruses.

In a busy shared environment it is not unusual for more than 50% of the machines to become unusable in one day due to system software being deleted or becoming corrupt. Considerable work is involved in cleaning up the systems and re-installing the system software. 860970 - 2 It is an object of the invention to provide a data protection apparatus for a computer workstation which can overcome or mitigate at least some of these disadvantages.

Accordingly, the invention provides an apparatus for protecting at least part of the data on a data storage medium of a computer workstation, the workstation having an operating system kernel which handles requests to transfer data to and from the storage medium, the apparatus comprising a device which is adapted to inspect each such request to determine if it is a request which would alter said at least part of the data and if so to refuse such request unless a predetermined condition, under the control of the workstation user, is met.

An embodiment of the invention will now be described, by way of example, with reference to the accompanying drawings, in which: Figure 1 is a memory map of a personal computer with an additional EPROM chip installed for hard disc protection, Figure 2 is a flow diagram of a utility program used to install the EPROM chip, Figure 3 is a flow diagram of the initialisation routine of the EPROM chip; and Figure 4 is a flow diagram of the interrupt 13 handler routine of the EPROM chip. 2a The embodiment of the invention is described in relation to an IBM or IBM-compatible personal computer (PC) running Microsoft MS-DOS or IBM PC-DOS, and which is fitted with a hard (fixed) disc drive, a floppy disc 5 drive and a network adapter card having a so-called boot PROM socket (such sockets are found on most network adapter cards). It is assumed that the PC has the operating system and network software set up on the C: partition (also referred to as the C: drive). Such computers are very well known and need no further description here.

The embodiment of the invention involves the modification of the hardware and software of the PC by the insertion of an EPROM chip (solid state circuit) containing special software into the boot PROM socket of the network card. The chip software exploits the hardware of the network adapter card to gain access to the PC busses, and it exploits existing software in the PC initialisation sequence, which automatically activates it, causing it to insert itself in the machine's software at a low level.

A general description of the operation of the additional EPROM chip (referred to hereinafter as an intercept chip) will first be given, followed by flow diagrams of the software programmed within the chip.

The intercept chip appears to the PC as an expansion ROM in the memory area between C800:0000 and F000:0000, see figure 1. As such, the computer's startup procedure will transfer control to it for initialisation purposes at the end of the power-on self test but before the bootstrap program is loaded from disc. The initialisation involves revectoring the computer's disc services BIOS interrupt (INT 13h) so that all INT 13 calls are passed to the chip. As is well known, the BIOS is the lowest level of operating software for the PC, often referred to as firmware, and is contained in a ROM chip supplied as part of the machine hardware.

The software programmed into the intercept chip performs two distinct functions. First, it allows the PC to be set up so that it cannot boot up from the floppy drive. To this end, all requests to the floppy 5 disc drive are refused by returning a not ready error code, simulating the absence of a diskette, until the chip software detects that the operating system (DOS) has been installed. However, should it become necessary to boot from floppy disk (in the event of CMOS RAM failure or new hardware installation, for example) a mechanism exists to allow this in a secure fashion. Thus, if the capital A key is pressed during initialisation by the intercept chip software, which occurs before the installation of DOS, the user is asked 15 for a password and if this is entered correctly, the system attempts to boot from the floppy disc as usual.

This function allows those responsible for the machine to prevent boot-up from a floppy disc, forcing a 20 boot-up which will use the AUTOEXEC.BAT file on the C: drive. This file can be set up so as to force user authorisation and login, or to limit access to a restricted environment only. In this way, use by unauthorised persons or for unauthorised purposes can be 25 curtailed. The AUTOEXEC.BAT file can also be set up to force a check of the complete system for viruses, including any files set up by users on the D: or other drives. In this way, a high level of management of both authorisation and integrity for the machines on a network is made easily possible.

Second, once the machine is up and running, the intercept chip software protects the files on the C: partition of the PC’s hard disc from erasure or modification by inspecting all INT 13 calls, i.e. disc transfer requests. Those that would cause a write or format to the C: partition of the hard disc are refused by returning a write protect error code, unless the chip has been disabled by the system administrator using a supplied utility program on floppy disc.

Thus, since it is assumed in this embodiment that the operating system and network software is set up on the C: partition, the intercept chip protects this from alteration or deletion, whether by user programs or by software viruses. Other drives, such as D:, are not affected and their contents may be set up and altered by the user as required.

The intercept chip is installed by first running a utility program contained on a floppy disc. The PC is then shut down, the chip physically inserted in the network adapter card boot PROM socket, and the PC re-booted. To de-install the chip, the utility program is used again, the PC is shut down and the chip removed. The utility program further allows a person responsible for the machines on the network and who knows the correct password to override the protection afforded by the installed intercept chip. The password may be unique to each machine on the network, but is preferably common to all the machines on the same network.

Clearly, the intercept chip will not prevent software from by-passing the computer's disc BIOS and issuing requests to change the hard disc contents by programming the disc controller's hardware registers fl directly. However, the wide variety of hard disc controllers (which are mutually incompatible at a ( hardware register level) available makes this an impractical proposition for practically all application software. Furthermore, there is rarely anything to be gained by not utilising the standard interface provided by the controller's onboard BIOS software and practically all commonly available application software . accesses the disc in this way.

V One notable exception is the popular Microsoft Windows 3.1 environment. If Windows detects that the hard disc controller is one particular model which is in common use (Western Digital 1003) it can be configured to by-pass the BIOS and issue requests to the controller directly. By doing so it gains a speed advantage over the BIOS method (because it does not have to switch the CPU mode or transfer data to its final destination via the lowest 1Mb of physical memory). In order to establish the feasibility of this access method, Windows performs a test when it is started which involves reading a sector using both methods. If the results are the same Windows assumes that it can perform direct hard disc controller access (known internally as 32BitDiskAccess). Otherwise it asstunes that the hard disc controller is not of the correct type and it does not attempt to by-pass the BIOS.

In order to coerce programs such as Windows into using the BIOS, the utility program performs a simple encryption on the complete C: drive when the intercept 25 chip is installed. This involves simply inverting the first 16 bits of every sector. The installed intercept chip now has to decrypt anything read from the C: drive and encrypt anything written to the C: drive. However, for a simple encryption algorithm as described above the 30 intercept chip software can perform the encryption and decryption with a minimal overhead (only a few tens of . machine cycles per sector which is negligible in comparison to the overhead of the data transfers). This ensures that any program which attempts to by-pass the BIOS to access existing material on the C:drive will not be able to do so. When the intercept chip is de-installed, the utility program decrypts the C: drive.

As well as ensuring that the computers in a shared environment are always usable from a software standpoint, because the software set up on the C: drive by those in charge of the system cannot be modified by unauthorised users, the embodiment of the invention significantly impedes the spread of computer viruses. PC computer viruses always take one of two forms: the first strain work by embedding themselves in the boot area of the disc. In this way they are installed by the computer's bootstrap procedure each time it is turned on. The second variety attach themselves on to executable files on the disc and are installed into the computer's memory when an infected executable is run. Since all the boot areas of the hard disc are write protected, the intercept chip eliminates the threat of the first variety of virus. Furthermore, the executables present on the C: drive cannot be modified and thus remain virus-free. Viruses will therefore not spread from system software to users.

Figure 2 is a flow diagram of the utility program on the floppy disc. When it is run, a welcome message is first displayed which requests confirmation that the program is to be run (step 20). According to the user response (step 21) either the program is aborted (step 22) or a determination is made whether the intercept chip is already present and active in the computer (step 23) . This latter determination is effected by issuing a pseudo call, which is an INT 13 request using a pseudo-function number.

At this point it should be explained that to allow DOS programs (and in particular the utility program) to communicate with the intercept chip a pseudo-function of INT 13h is provided. This function has no meaning to the computer's ROM BIOS but is intercepted by the intercept chip which recognises the function code as an instruction to itself. The following functions are provided by this mechanism: Detect presence of intercept chip - a null function which can be used to detect the presence of the intercept chip active in the system.

Enter supervisor mode - this function is used to switch the chip into supervisor mode, as described below.

Leave supervisor mode - Returns the chip to normal 15 operation.

Returning now to figure 2, if the intercept chip is not present, it is assumed that the user wishes to install the chip on the network adapter card. Thus the 20 hard disc is checked (step 24) to ensure that the first (C:) partition contains the DOS operating system, and if so (step 25) the data on the C: drive is encrypted cylinder by cylinder (steps 26 to 28) until all the data on the C: drive is encrypted (step 29).

When encryption is complete, the utility floppy is withdrawn from the floppy disc drive, the PC is shut down, and the intercept chip inserted in the boot PROM socket of the network adapter card. Then the PC is 30 re-booted.

Returning to step 23, if the intercept chip is already active it is assumed that the user wishes to switch the chip into or out of supervisor mode.

Supervisor mode is a mode which permits the C: drive to be written to, thus overriding the protection normally afforded by the intercept chip. It can only be entered and left under password control. Thus the user is prompted for the password (step 30) and upon receipt of the correct password (step 31) a pseudo call is issued to the chip (step 32), either to switch the chip into supervisor mode if it wasn’t already or to switch it out of supervisor mode if it was.

At this point it should be further explained that the password is stored in an encrypted form on the chip. When a user-supplied password is received (either as part of a request to enter or leave supervisor mode as just described or, as will be described, during initialisation in the course of an attempt to boot from floppy disk) it is encrypted and the result of this encryption is compared with the value stored in the intercept chip.

Further, while the intercept chip is in supervisor mode the un-encrypted password supplied by the user is retained in storage at a designated location in the intercept chip RAM area (figure 1) . Then, when a restricted request (a write or format to the C: partition of the hard disk) is received the password stored in RAM is encrypted and compared with the value in ROM. This happens for EVERY restricted request, removing the need to set a flag in memory to indicate supervisor mode. Such a flag would pose a security risk as a skilled programmer could reverse-engineer the on-chip software and manually set the flag without knowing the password. Thus supervisor mode is effectively defined by the presence of a correct un-encrypted password in the designated storage location, and is removed from that location when the chip leaves supervisor mode. The password is placed in and cleared from the designated storage location by issuing a pseudo-call from the utility program, as described above.

Thus, to summarise, the function of the utility ύ program is to prepare (encrypt) the data on the C: partition of the hard disc prior to installation of the intercept chip on the network adapter card of the PC or, if the chip is already installed, switch it between supervisor and non-supervisor modes. Another function of the utility program is to decrypt the data on the C: partition when it is desired to remove the chip from the PC. However, this is essentially the reverse of the encryption shown in figure 2 and it is not thought necessary to give details.

For security reasons the utility program must be run off the original diskette. When it is run it verifies that the disk is not a copy by checking for a timing irregularity which is deliberately introduced onto the disk during production and which is not preserved by 20 copying the disk's files or by using DOS's DISKCOPY program to copy the disk. This copy protection method is known, and therefore does not need further description.

Figure 3 is a flow diagram of the initialisation 25 routine of the installed intercept chip, which is executed when control is passed to the chip during the PC’s startup procedure.

First (step 42) the chip allocates RAM to itself by 30 decrementing the system variable which stores the number of kilobytes of conventional (i.e. first 1Mb) RAM in the system. Thus it ensures that DOS will neither use not allocate the top IK of conventional memory, thereby reserving it to the intercept chip. Next it attempts to 35 read the hard disc partition table (step 43) and if successful (step 44) a hard disc enabled flag is set (step 45) whereas if unsuccessful control returns to the BIOS (step 46).

Now (step 47) the intercept chip software re-vectors the computer's disc services BIOS interrupt (INT 13h), as discussed above, after which it takes a copy of the current value of the INT 21h interrupt vector (step 48). This will be a garbage value since no software will have been loaded on the machine at this point. This value is simply stored for later reference.

At step 49 the intercept chip checks to see has the capital A key been pressed by issuing a BIOS keyboard services call - INT 16h - to peek” at the next character in the keyboard buffer. If it has, the chip prompts for its password (step 50) and reads the user's response. If the correct password is entered, i.e. the encrypted version of the user's inputs matches the encrypted on-chip password (step 51), then an allow floppy boot flag is set (step 52).

The particular moment chosen by the user to press the A key is important. Obviously, it must be done before the intercept chip software checks the keyboard buffer during its initialisation. It is important, however, not to press it before the computer's power-on self test has initialised the keyboard or the keystroke will not be recorded. As the keyboard is always initialised before the intercept chip, however, there is a reasonable window of time during which the keystroke will register (7 or 8 seconds).

Figure 4 is a flow diagram of the interrupt 13 handler routine of the intercept chip. The software first checks (step 60) to see whether the INT 13 request is a pseudo-call. If so, it switches the intercept chip into or out of supervisor mode as previously discussed (step 61) or, where the call is issued in response to step 23 of figure 2, it returns the appropriate response to the utility program.

Otherwise, the software checks (step 62) to see if is a request to access the floppy disc drive, and if so it checks (step 63) to see of the allow floppy boot flag was set at step 52 during initialisation. If the flag is set the request is passed to the BIOS (step 74) and the computer boots from the floppy disc.

If a floppy boot is not allowed (flag not set), the software checks (step 65) to see if DOS is loaded yet. This is done by comparing the present value of the INT 21h vector with that stored at step 48 during initialisation. If the two values are the same, then DOS has not yet been loaded and the intercept chip can be sure that the read request it has intercepted is an attempt to boot from a floppy disk. In this case, the software returns a device not ready error (step 66) 20 simulating the absence of a floppy disk in the drive.

The computer's ROM BIOS will then go on to boot from the hard disk.

It will be noted that all subsequent (after the computer has booted) requests to the floppy disk drive will be likewise intercepted. However, since the INT 21h vector will by then not contain the same value as it did during initialisation (because DOS captures INT 21h), at step 65 the intercept chip software will allow all floppy disk requests to proceed normally.

Returning to step 62, if the request is not a floppy disc request, then it must be a hard disc request, and the hard disc enable flag is checked (step 67) . If it 35 is not set an error code is returned (step 68). However, assuming the flag is set, a check is made (step 69) to see if it is a request to the first hard disc (it is assumed there may be more than one hard disc). If so, it is then checked to see if it a write or format request to the first partition (C: drive) of the hard v disc (steps 70 and 71).

If the request is not a write or format to the first partition of the first hard disc, it can be processed normally, and control is passed to the BIOS (step 74). Otherwise, if the request IS a write or format to the first partition of the first hard disc, the software checks (step 72) to see if the chip is in supervisor mode, by password comparison as referred to earlier. If the chip is not in supervisor mode the request is refused (step 64) by returning a write protected error code. However, if the chip is in supervisor mode, the request can be processed as normal through steps 73 to 78.

Thus, it is checked for being a read request (step 73) and if so the BIOS is called to read the disc (step 75) and the read data is decrypted (step 76). If it is not a read request it is checked for being a write request (step 77) and if so the data to be written is encrypted (step 78) and the request passed to the BIOS (step 74) to write the data to the disc. If it is not a read or write request it must be a format request and that too is passed to the BIOS.

Various modifications are possible to the above embodiment. For example, while the above embodiment is essentially concerned with the retrofitting of an , v intercept chip after a machine has been purchased, the intercept chip may be supplied installed in new machines. In such case the utility program (figure 2) would only be needed to switch into and out of supervisor mode, since all data would be encrypted from the first time the disc was used. It would also be possible in such cases to provide the BIOS and intercept software in a single ROM chip.

Further, while the embodiment envisages the utility program being run to encrypt the data before the intercept chip is inserted in the machine, it could be modified to permit the chip to be installed beforehand.

In that case the utility disc would be made as a boot disc and shift-A would be pressed on the keyboard during initialisation. Then, after booting from the floppy disc, the data would be encrypted as previously described.

Claims (5)

1. An apparatus for protecting at least part of the data on a data storage medium of a computer workstation, 5 the workstation having an operating system kernel which handles requests to transfer data to and from the storage medium, the apparatus comprising a device which is adapted to inspect each such request to determine if it is a request which would alter said at least part of 10 the data and if so to refuse such request unless a predetermined condition, under the control of the workstation user, is met.

2. An apparatus as claimed in claim 1, wherein the data 15 storage medium is a hard disk whose data is organised into at least one partition, and the protected data is the data contained within the said at least one partition. 20

3. An apparatus as claimed in claim 2, wherein the device is further adapted to encrypt data written to the said at least one partition and to decrypt data read from the said at least one partition. 25

4. An apparatus as claimed in claim 1, wherein the computer workstation is part of a computer network and has a network adapter card, and the device is a solid state chip which plugs into a socket on the card. 30

5. An apparatus as claimed in claim 1, wherein the said predetermined condition is the presence at a predetermined location in the computer memory of a password, entered manually by the user, which is the same as a password contained in the device.