WO2006090091A1

WO2006090091A1 - User authentication for a computer system

Info

Publication number: WO2006090091A1
Application number: PCT/GB2005/000675
Authority: WO
Inventors: Timothy David Stone; Anthony Howard Stead
Original assignee: Stonewood Electronics Ltd
Priority date: 2005-02-23
Filing date: 2005-02-23
Publication date: 2006-08-31
Also published as: EP1920304A1

Abstract

A user of a computer having a USB interface can be authenticated by providing a security device. The security device is attached to the USB interface via a USB adapter. A boot program is initiated on the computer. The boot program supports USB communications with a first device type. Communications are performed between the boot program and the security device to authenticate the user via the USB adapter. The USB adapter emulates the first device type to the boot program to perform the communications.

Description

USER AUTHENTICATION FOR A COMPUTER SYSTEM

Field of the Invention

The present invention relates to user authentication for a computer system, and in particular to performing such authentication when the system is started.

Background of the Invention

When a personal computer or similar device is first switched on (or reset), a boot process is performed. The processor accesses the basic input/output system (BIOS), which is normally stored in a read only memory (ROM) or flash memory (a form of programmable ROM). The processor then executes the BIOS code to implement the boot process, which typically includes performing certain system configuration operations and running a Power-on Self Test (POST) program. Once this has been completed, the BIOS code loads the operating system for execution by the processor, whereupon the system is now ready for user operation.

In the very first version of the IBM PC there was no hard disk drive, and the boot process had to load the operating system from a floppy disk. Subsequent personal computers incorporated a hard (fixed) disk unit, and the operating system was generally stored (often pre-installed) on this hard disk drive. Nevertheless, the BIOS usually still examined the floppy disk unit first to see if it contained a disk with an operating system (i.e. a bootable floppy disk), and only then loaded the operating system from the hard disk drive if no such floppy disk was present. One reason for this approach is that if the operating system on the hard disk drive had become corrupted, it would still be possible to install a new (working) operating system into the machine. In other words, the BIOS in most machines would look first to load the operating system from the floppy disk drive in preference to the hard disk drive, and only load the operating system from the latter if there was no suitable floppy disk in the former. This history is reflected even in modern PCs, where the floppy disk unit is normally denoted as the A drive, and the hard disk unit is the C drive. In recent years, the Universal Serial Bus (USB) has become the most common way of connecting a wide range of peripheral devices to a personal computer. USB provides a master-slave protocol, in which all transactions are initiated by a host machine (the personal computer). Like other communications facilities, USB involves a layered structure. Figure 1 is a simplified schematic diagram of this structure, and shows a host device 10 communicating with a peripheral device 20 via a USB connector 101. The host device 10 includes a stack comprising a USB controller 11 at the bottom (hardware), then a USB driver module 12 (system software), then a USB device driver 13, and on top a client application 14. Note that peripheral device 20 will generally include a corresponding stack (not shown in Figure 1).

The USB standard supports enumeration, whereby when a peripheral device 20 is attached to a host 10, the host interrogates the peripheral device to determine an appropriate device driver 13 to load, since the correct device driver is dependent upon the particular nature of peripheral device 20. Certain device drivers for some standard device types are generally included as part of the operating system, while other peripheral devices may require their own, more specialised device driver. Further details about USB are available from www.usb.org.

One type of device that may be attached to a personal computer via a USB interface is a security system. Such a system can be used to control user access to machine function, including data, applications and/or networks. The security system may be based on some physical token, perhaps a smart card or key, or may utilise biometric information, such as fingerprints, retinal scan, and so on. The security system authenticates the user for access to the restricted functionality or material. This sort of security system is commercially available from (among others) Aladdin Knowledge Systems Ltd (see www.aladdin.com), and SafeNet Inc (see www.safenet-inc.com).

hi some cases, the security device may not support USB directly, hi this situation, a USB adapter may be interposed between the host system and the security device. This is illustrated in Figure 2, where host system 210 and authentication device 220 communicate via USB adapter 215. The USB adapter 215 receives USB commands from the host system 210 over USB connector 201, and translates them into a format suitable for communication to authentication device 220 over connector 221. Conversely, the USB adapter 215 receives communications from authentication device 220 over connector 221, and then translates them into USB responses to return to host system 210 over USB connector 201. Note that connector 221 may be a form of wireless connection, such as IrDA.

Authentication devices are not normally used at boot time. One reason for this is that the BIOS code on most personal computers generally has very limited support for USB communications. Rather, such security devices typically perform their authentication after the operating system has loaded, when full USB support is available within the machine. However, this represents a potential security weakness, since the operating system is much easier to subvert than the BIOS code. This is partly because the BIOS may be hard-coded into ROM, and so cannot be altered, unlike the operating system, which is stored on a hard disk drive, and where it can be modified, corrupted, or extended in various ways. (Even if the BIOS is stored in flash memory, which is more common in modern systems, it is still relatively difficult to change compared to the operating system files stored on disk). In addition, modern operating systems are extremely large and complex, and so inevitably have certain security flaws that can potentially be exploited by an adversary. As a result, there is a risk that the operating system might be compromised during loading or initialisation in such a manner that authentication by any security system is bypassed or otherwise corrupted. This could then allow a user to gain unauthorised access to data or services provided by the machine.

The Flagstone product from Stonewood Electronics (see www.stonewood.co.uk) encrypts an entire hard disk drive for security protection (such a device is also described in WO 03/012606). The material on the hard disk drive can then only be accessed if a user passes the appropriate authentication process. If the operating system is stored on the hard disk drive, this is encrypted as well, and cannot be loaded and executed except by an authenticated user. However, as previously mentioned many security systems attach via USB, and so require the operating system to be loaded in order to perform their authentication. This can lead to a conflict, where the operating system cannot be loaded until after the authentication has been performed, while the authentication cannot be performed until after the operating system has loaded. Summary of the Invention

Accordingly, one embodiment of the invention provides a method of authorising use of a computer. The method involves attaching a security device for authorising use of the computer to a USB interface of the computer via a USB adapter. The method further involves initiating a boot program on the computer, where the boot program supports USB communications with a first device type (N.B. the boot program may be initiated before or after attachment of the security device). The method further involves communicating between the boot program and the security device via the USB adapter to authorise use of the computer. The USB adapter emulates the first device type to the boot program during the communications.

Such an approach is more secure than existing techniques, in that the authorisation is done during the boot program, and can therefore be completed prior to loading the operating system. Consequently, there is less risk that the authorisation or authentication is somehow subverted by modification or corruption of the operating system. Although the boot program generally supports only a subset of the full range of USB device types (and this does not normally include security devices), in the present approach the boot program is able to communicate with the USB adapter because the latter emulates a device type supported by USB functionality available to the boot program.

In one particular embodiment, the first device type comprises a bootable device type, for example a mass storage device type, such as a floppy disk unit. A boot program generally has USB support for such a bootable device, since it may need to access the device in order to load an operating system (in other words to complete the boot). In another embodiment, the first device type comprises a keyboard. Again, it will be appreciated that a boot program generally has USB support for a keyboard device, since the latter might be used to input configuration or other information during the boot process.

In one embodiment, the security device is used to perform a biometric and/or token-based authentication (although other forms of security device could be used instead). The security device obtains information from a prospective user of the computer (e.g. as biometrics or from a token possessed by the user). This information can then be used to authenticate the user by verifying against stored information, for example biometric or token details for authorised users. Note that this stored information about authorised users may not be stored on the security device itself, but may rather be located somewhere else, such as within the computer, and may be stored in any appropriate form (e.g. protected by a one-way function). Likewise, the verification of the information from the security device against the stored information may not be performed on the security device itself, but may be performed on the computer or on some other appropriate system.

In some embodiments, the USB adapter may be integrated into the security device itself. This then provides a complete security device that can be directly connected to a USB port of a computer. Alternatively, the USB adapter may be provided as a separate unit to act as an intermediary between the computer and the security device, thereby allowing a wide range of security devices to be supported. In the latter case, a single USB adapter may be able to support multiple security devices (e.g. one token-based and one utilising biometrics).

In one embodiment, the USB adapter stops emulating the first device type after the boot program on the computer has completed. At this point, the operating system has generally been loaded, including full USB functionality. The USB adapter can therefore revert to its native or most natural USB device type, which normally helps efficiency in communications between the host computer and the USB adapter, in addition, ending the emulation avoids the risk of any confusion to the user (for example, if the USB adapter emulates a floppy disk unit, a user might try to save a file to it).

hi one embodiment, the USB emulation supports a read command for the first device type to access the security device. Such a read command can be used to obtain authentication data acquired by the security device, for example for authorisation, hi some embodiments, the USB emulation also supports a write command for the first device type to access the security device. Such a write command may be used to specify a security setting associated with the security device, for example to write data into a token currently located in the security device, or perhaps to provide comparison data to the security device for use in subsequent biometric testing. In one particular embodiment, data read from successive accesses to a fixed location within one or more predetermined sectors of the security device is toggled, so that at least some of the data bits are flipped between successive reads. It will be appreciated that this behaviour distinguishes the USB adapter from a normal data storage device, where the read output from a given location will generally be constant across all read operations (providing there is no intervening write operation). This therefore provides a mechanism for a boot program to verify, if desired, that it is communicating with an emulated storage device, as opposed to a real storage device.

In some embodiments, the processing described above may be incorporated directly into the standard boot program of the computer. In other embodiments, the main boot program of the computer may be configured to invoke some other boot code to control the authorisation. For example, the boot program may invoke code from the security device itself using the USB communications. In another embodiment, the computer includes a secure hard disk drive, and the boot program includes code invoked from the secure hard disk drive.

Another embodiment of the invention provides apparatus comprising a first interface for connecting to a USB host via a USB connector and a second interface for connecting to an authentication device. The apparatus further comprises a USB emulator linked to the first and second interfaces to serve as an intermediary for communications between the USB host and the authentication device. The USB emulator is operable to emulate a BIOS-supported device with respect to the first interface.

Another embodiment of the invention provides a computer system comprising a USB host, an authentication device, and a USB adapter. The USB adapter includes a first interface for connecting to the USB host via a USB connector, a second interface for connecting to the authentication device, and a USB emulator. The USB emulator is linked to the first interface and to the second interface to serve as an intermediary for communications between the USB host and the authentication device. The USB emulator is operable to emulate a BIOS-supported device with respect to the first interface. It will be appreciated that the apparatus embodiments of the invention will generally benefit from the same particular features as the method embodiments of the invention.

Brief Description of the Drawings

Various embodiments of the invention will now be described in detail by way of example only with reference to the following drawings: Figure 1 is a schematic diagram of a host device linked by a USB connector to a peripheral device;

Figure 2 is a schematic diagram of a host device linked to an authentication device via a USB adapter;

Figure 3 is a schematic diagram of a USB host in accordance with one embodiment of the invention;

Figure 4 is a schematic diagram of a secure disk drive from the USB host of Figure 3 in accordance with one embodiment of the invention;

Figure 5 is a flowchart depicting the power-on and authorisation sequence of a USB host in accordance with one embodiment of the invention; Figure 6 is a schematic diagram of a USB authentication device in accordance with one embodiment of the invention;

Figure 7 is a flowchart illustrating USB emulation by the USB authentication device of Figure 6 in accordance with one embodiment of the invention;

Figure 8 is a schematic diagram of boot code used by the USB host of Figure 3 in accordance with one embodiment of the invention;

Figure 9 is a flowchart illustrating in more detail the authentication procedure from the flowchart of Figure 5 in accordance with one embodiment of the invention; and

Figure 10 is a flowchart summarising the power-on and authorisation sequence of a USB host and USB authentication device in accordance with one embodiment of the invention.

Detailed Description Figure 3 illustrates a host system 410. The host system includes a processor 415, a programmable read only memory (PROM) 420 and a hard disk drive 430. The PROM 420 stores BIOS code 421 for the host system. The host system 410 further includes a USB controller 411 and supports the attachment of USB cable 301. Host system 410 may be implemented as a personal computer or other such device. It will be appreciated that host system 410 will generally include other components, such as a keyboard, and a display unit, which have been omitted from Figure 3 for reasons of clarity.

Figure 4 is a schematic diagram of hard disk drive unit 430 in more detail, which in this particular embodiment represents a secure unit. The hard disk drive includes a PROM 520 containing boot code 521. The hard disk unit further contains a key store 525 comprising volatile memory, such as a register or some form of random access memory (RAM). The key store 525 may also include some non-volatile (solid state) memory, such as a PROM. The key store 525 is used to hold one or more keys for encryption/decryption and/or authentication, as described in more detail below. The hard disk drive 430 further includes a disk storage system 530 which is accessed via an encrypt/decrypt (EfD) unit 535. The E/D unit 535 uses key information held in the key store 525 to encrypt data being saved into the disk storage system, and to decrypt data being read from the disk storage system.

Figure 5 is a flowchart illustrating the initial operation of host system 410 when the system is first powered on, in accordance with one embodiment of the invention. After power-on (operation 701), the BIOS code 421 in PROM 420 is loaded onto processor 415 and starts executing (operation 710). The BIOS code 421 is configured to invoke the boot code 521 stored in PROM 520 within secure hard disk unit 430 (operation 720). The boot code checks whether an authenticated key is available in key store 525 (operation 730). At this stage, no such authenticated key should be available, since this data is stored in volatile memory in key store 525, and will therefore be empty at power on. Accordingly, the boot code 521 performs an authentication, the results of which can be saved into key store 525 (operation 740). The manner in which this authentication is performed is described in more detail below. A test is made to see whether the authentication has been successful (operation 745). If the authentication has not been successful, processing exits with an error (operation 749). Note that a user may be allowed a certain limited number of attempts to perform the authentication before the authentication is determined to have definitely failed. In some implementations or configurations, a failed authentication at operation 745 may imply that the boot program aborts, and the host system 410 cannot be used at all. In other implementations, the main BIOS code 421 maybe allowed to continue executing after such an error, but the host system 410 is not allowed to access secure disk drive 730 (which may prevent it from loading an operating system). Another possibility is that authentication failure at operation 745 may put the host system 410 and/or hard disk drive 430 into some protected mode, such that it (they) can only be subsequently accessed by some special restricted mechanism.

Assuming now that the authentication has been successful (i.e. a positive outcome from operation 745), the boot code 521 now triggers a reset or reboot within host system 410 (operation 750). This causes the BIOS code 421 from PROM 420 to start executing again, thereby returning to operation 710. As before, the BIOS code 421 invokes the boot code 521 from PROM 520 (operation 720), which again checks whether an authenticated key is available (operation 730). This time the outcome from the test of operation 730 should be positive, since the results from the authentication at operation 740 will be available in key store 525. (N.B. The reset at operation 750 did not deprive the key store 525 of power, thereby allowing the authenticated key to be retained within the volatile memory of key store 525).

On detecting that the authenticated key is available, the boot program 521 terminates, and processing returns to the main BIOS program 421 (operation 760). The BIOS program is now able to access disk store system 530 via E/D unit 535, and therefore to load the (encrypted) operating system from secure hard disk drive 430 for execution by processor 415 (operation 770). Accordingly, host system 410 is now available to be used in normal fashion (exit 799).

It will be appreciated that there are various alternative approaches for implementing the system start-up procedure illustrated in Figure 5. For example, in one embodiment, there is a choice of boot code to load from the secure disk drive 430, and this choice depends on whether or not an authenticated key is available at operation 730. If not, boot code 521 is loaded and run in order to perform the authentication at operation 740. On the other hand, if an authenticated key is indeed available, an O/S loader (not shown in Figure 5) from the secure disk drive 430 is started in order to load the operating system at operation 770. The skilled person will be aware of further possible variations on the processing of Figure 5.

It will be appreciated that there are various mechanisms for operating key store 525 in order to control access to the encrypted disk storage system 530. Assuming that host system 410 includes a display unit and a keyboard, the user can be prompted to enter a password by the boot program 521. hi some systems, the entered password may then be used directly as a decryption key, so that if an incorrect password is supplied, the output will not be meaningful. Another approach is to store a password and an encryption/decryption key within key store 525 (both in non-volatile memory). The password may be encoded by a one-way function, such that the actual password itself cannot be retrieved. In operation, a user enters a password, which is transformed by the one-way function, and compared with the expected result. If there is a match, a flag is set (in volatile memory), which then allows access to the saved encryption/decryption key for use by E/D unit 535. However, if the flag is not set, E/D unit 535 is prevented from accessing the saved encryption/decryption key, and so cannot read from or write to secure disk storage 530. The skilled person will be aware of various other suitable mechanisms for the operation of key store 525 and E/D unit 535.

An authentication or authorisation process based on passwords has certain weaknesses from a security perspective, for example, a password may be guessed, copied or intercepted. Other authorisation procedures may therefore utilise physical tokens, such as smart cards, to perform authentication. In other words, a user is only authenticated if he or she is in possession of a particular token (this is analogous to the situation with a physical key). Another authentication approach is based on biometrics (e.g. fingerprints, retinal scans, etc) to confirm that a user really is the person that he or she claims to be. In some implementations, authentication may be based on a combination of two or more different strategies (passwords, tokens, and biometrics), in which case key store 525 may be used to hold multiple different key parameters. Although passwords can normally be entered via a keyboard, other forms of authentication, such as token-based or biometrics, generally involve the use of a specialised authentication device, usually external to a host system.

Figure 6 is a schematic diagram of a USB authentication device 300 in accordance with one embodiment of the invention. Note that this diagram omits certain standard components (e.g. a clock) that are not directly relevant to an understanding of the present invention. USB authentication device 301 can be regarded as performing three main functions: a) user authentication - as for device 220 in Figure 2; b) USB adapter - as for device 215 in Figure 2; and c) USB emulation.

In the particular embodiment of Figure 6, these three functions are all integrated into a single device. However, the functions may be implemented in three separate devices, or two of the functions may be implemented in one device, and the remaining function in a second device. For example, one implementation may provide a combined USB emulator and adapter, which then works in conjunction with a separate authentication device. (In this latter case, the general configuration would then correspond to that shown in Figure 2).

The USB authentication device 300 utilises the iButton system, which is commercially available from Maxim Integrated Products, me, USA. The iButton system provides a physical token about the size of a coin or button, for example the DS1971 Dallas iButton F3/F5 microcan or the DS1973 Dallas iButton F3/F5 microcan, which can both be used for secure, robust storage of a key or other authentication parameter. The USB authentication device 300 includes an iButton receptor 319, which offers a read/write interface to an iButton microcan. The iButton receptor 319 is linked to an iButton serial 1-wire driver 316 that is used for controlling the iButton receptor 319 via a 1-wire connector 321 and ESD protection 318. In one particular embodiment, the iButton serial 1-wire driver is implemented by a Dallas DS2480 chip, and the ESD protection is implemented by a Dallas DS9503 chip (both available from Maxim Integrated Products). Further details about the iButton system can be found at: httpV/www.maxim-ic.com/l-Wire.cfm. The combination of the iButton serial 1-wire driver 316, the ESD protection 318, the 1-wire connector 321 and the iButton receptor 319 provides an authentication device, but one which (by itself) does not have direct support for USB. Therefore USB authentication device 300 acts as a form of USB adapter to allow host system 410 to connect to the iButton system via USB. hi particular, USB authentication device 300 includes a USB connector 305 for receipt of a USB cable 301 (which may in turn be connected to host system 410). The USB authentication device 300 also includes a protector 312 attached to the USB connector 305 to protect against transient voltage surges on the USB cable 301.

The USB authentication device 300 further includes a power regulator 311, which in one embodiment comprises a 2986A IM3.3 chip available from National Semiconductor Corporation USA (see http://www.national.com/). The power regulator 311 extracts power from the USB cable 301 (as supplied from the host system 410), and provides power to the various components within the USB authentication device 301. The power regulator 311 may also be responsible for converting the 5 volt supply received over the USB cable 301 into any other voltage required within authentication device 300. In one particular embodiment, the power regulator provides a 3.3 Volt supply to the USB emulation device 314.

The USB emulation device 314 acts as a combined USB adapter and emulator. The USB emulation device 314 receives USB commands from host system 410 over USB cable 301, and generates an appropriate response to these commands to return to the host system. The USB emulation device 314 is also connected to the iButton serial 1-wire driver 316 (via an RS232 link), which allows the USB emulation device 314 to send control messages and write data to the iButton receptor 319, and to receive data from the iButton receptor 319. Ln one embodiment, the USB emulation device comprises a microcontroller, in particular the AN2131SC device available from Cypress Semiconductor Corporation, USA. This device incorporates generalised support for USB communications, and is then programmed for more specific behaviour to provide the USB emulation described in more detail below.

hi accordance with one embodiment of the invention, USB emulation device 314 is configured to emulate a floppy disk unit (FDU). The skilled person will appreciate that although USB emulation device 314 has to appear to the host system 410 as some kind of USB device in order to act as a USB adapter for the iButton authentication device (such as in the configuration of Figure 2), it would not normally be expected for the USB device to appear as a floppy disk unit. This is because within the context of USB, a floppy disk unit is a predefined class of device having certain properties that do not generally map onto the behaviour of an authentication device, such as the iButton system. However, the motivation for USB emulation device 314 to emulate a FDU will become apparent later.

The set of commands supported by a USB FDU is defined in the specification:

"Universal Serial Bus, Mass Storage Class, UFI Command Specification", the contents of which are hereby incorporated by reference into the present specification, and which is available from: http://www.usb. org/developers/devclass_docs/usbmass-ufil0.pdf. Table 1 below represents the required UFI commands, with the first three columns taken from Table 1 of the above-referenced specification. The final two columns indicate the nature of the support provided by USB emulation device 314 as part of its FDU emulation.

As shown in Table 1 , there are three UFI commands that are not supported by the FDU emulation of USB emulation device 314. For the "Format Unit" command, the FDU emulation returns a "Write Protected" error code, while for the "Rezero Unit" and "Seek(lO)" commands, the FDU emulation returns a "No Disk in Drive" error. It will be appreciated therefore that although these three commands are unsupported, they nevertheless provide responses to the host system that are consistent with USB authentication device 300 actually being a FDU. Therefore, the program on the host system 410 that sent the unsupported commands should be able to handle reasonably the error responses returned.

For the majority of the supported commands, the USB device provides a positive response to the host system 410, although the data in the response may not have any direct meaning in the context of USB authentication device 300. For example, the information requested in the Mode Sense command includes the capacity of the (emulated) FDU. The USB device 314 returns any plausible value here, e.g. 1.44MBytes, thereby allowing the host system 410 to continue USB communications on the (presumed) basis that USB authentication device 300 is a FDU. This is indicated in Table 1 as a "dummy response". For certain other commands, the dummy response may simply indicate that the relevant command has been received and implemented, although the USB emulation device 314 has not in fact taken any meaningful action in response to the command (the Prevent/ Allow Medium Removal is an example of this).

For the two Read commands, the FDU emulation of USB emulation device 314 only supports read operations from sectors 0, 5, 6, 7, and 33. If a read is attempted from any other sector, the USB device returns a No Disk in Drive error. In addition, a Read command for sectors 0 or 33 is provided mainly to support other potential embodiments, but is not used directly in current embodiments. For example, the Read from sector 0 may be utilised directly by BIOS code 421 in host system 410 rather than boot program 521, since this is the sector where BIOS code would normally look for a boot record. (As discussed in more detail below, in some implementations boot program 521 may be absent, with the secure boot being performed instead directly by BIOS code 421).

A Read command for sector 6 or 7 causes the USB emulation device 314 to use the iButton serial 1-wire Driver 316 to send a command to the iButton receptor 319 to read an iButton microcan, and in particular to read the key stored in the microcan (the two different sectors are used for reading two different types of iButton microcan). The data obtained by the USB emulation device 314 from the iButton receptor 319 is then returned to the host system 410 as the response to the Read command.

A Read from sector 5 returns various status information to the host system 410, including the serial number and type of the iButton microcan (if any) currently associated with the iButton receptor. In one particular embodiment, USB emulation device 314 toggles certain predetermined bits in its response to successive Reads commands from sector 5. The reason for this will be described in more detail below.

Figure 7 is a flowchart summarising the FDU emulation by USB emulation device 314. The USB emulation device receives a UFI command from the host system 410 (operation 910), and determines whether or not this is a supported UFI command (915). If not, the USB emulation device 314 returns an appropriate error message (operation 920), such as No Disk in Drive or Write Protected, as discussed above. If the received command is supported, the USB emulation device now determines whether it needs to access the token - i.e. the iButton microcan in the embodiment of Figure 6 (operation 925). If no access to the iButton system is required, the USB emulation device 314 can send a response to the command directly back to the host system 410 (operation 930). In most cases this will be a dummy response, in that it conforms to the appropriate USB format for response to the received command, but contains no meaningful information relating directly to the iButton system. (In response to the UFI Inquiry command, USB emulation device 314 may return information about itself or USB authentication device 300 in general).

If the received command does represent an attempted read/write access to the FDU, then the USB device in turn interacts with the iButton serial 1-wire Driver 316 to access an iButton device via iButton receptor 319 (operation 935). This access may represent a read or write operation, depending upon the received UFI command. Once the access has been completed, the USB device 314 now returns an appropriate response back to the host system 940 (operation 940). This response might include data obtained from the iButton (following a UFI Read command), or might indicate a No Disk in Drive error if the access could not be completed (for example, because no iButton token was present at iButton receptor 319).

As shown in Table 1, the emulation of USB emulation device 314 also supports two Write commands (and also the Write and Verify command). In particular, the FDU emulation of USB emulation device 314 supports write operations to sectors 6 and 7, otherwise the USB emulation device returns a Write Protected error. A Write command for sector 6 or 7 causes the USB device 314 to use the iButton serial 1-wire driver 316 to send a command to the iButton receptor 319 to store data (e.g. a key) into the iButton microcan, where the data to be stored is specified in the Write command (again, the two different sectors are used for accessing two different types of iButton microcan).

Storing a key into an iButton token maybe useful if (for example) secure disk drive 430 has not yet been associated with a particular token. In this case, the boot program 521 may determine that it does not yet have an authentication key present in key store 525. The user can then be prompted to input such a key, which is both saved to non- volatile memory of the key store 525 and also written to the iButton token present at the USB authentication device 300. This ensures that subsequent access to the secure disk drive 430 is restricted to the holder of that particular token. Various other security protocols can also be implemented (these may include multiple layers of protection, for example to handle the possibility of a lost token).

Note that the FDU emulation by USB authentication device 300 is not limited to communications with boot code 521. Rather, once authentication device 300 has been enumerated as a USB FDU device, it becomes available to any other portion of BIOS code 421 that may try to communicate with such a USB-attached FDU. The FDU emulation is therefore able to provide reasonable responses to all potential incoming USB commands in order to avoid causing problems within BIOS code 421.

It will be appreciated that the emulation scheme discussed above and set out in Table 1 is provided by way of example only, and other embodiments may use different emulation schemes. For example, some implementations may implement the "Verify" command by reading data from the iButton receptor, and comparing this with previously saved data.

Figure 8 illustrates the interaction between the boot code 521 and the BIOS code

421 in accordance with one embodiment of the invention. For the authentication process (corresponding to operation 740 in Figure 5), the boot code 521 makes an interrupt 13 call into the BIOS code 421. An interrupt 13 call is a standard mechanism to call BIOS code in order to access a mass storage device, and accordingly BIOS code 421 will generally include support 652 for such interrupt 13 calls.

BIOS code 421 further includes USB support 654, in other words support for communications with USB devices attached to host system 410 via USB cable 301. However, the range of USB devices supported by BIOS code 421 is generally much more limited than the range of USB devices supported by an operating system. In particular, support is limited to those types of device that the BIOS code might reasonably need to access during the boot process, for example, a keyboard and display screen. Most BIOS implementations also include USB support for mass media devices (shown as support 656 in Figure 8), because a mass media storage device may contain an operating system or other code for use by the boot process.

Note that from the perspective of boot code 521, the interrupt 13 call is directed in effect to a local (i.e. internal) mass storage device (rather than to a device specifically attached by USB). However, the BIOS code 652 is responsible for recognising that the relevant mass storage device is attached via USB rather than being internal to the host system 410, and then using USB support 654, 656 to access the device (transparently to the boot code 521).

Figure 9 is a flowchart of performing the authentication of operation 740 from Figure 5 in accordance with one embodiment of the invention. The boot code 521 makes an interrupt 13 call into the BIOS code 421 (operation 805). The BIOS code has recognised that there is (apparently) an FDU attached via USB, and now determines that this BIOS call is intended for this FDU. Accordingly, the BIOS code sends an access request to the FDU - i.e. to USB authentication device 300 (operation 810). This USB command attempts to read from sector 5 of the FDU. If there is no token yet available (operation 815), which can be indicated by a No Disk in Drive response from the USB emulation device 314 (or else by returning some predefined data in response to the read command), the processing loops back to retry the access (possibly up to some maximum number of times).

Assuming that a token is indeed present at the USB authentication device 300, USB emulation device 314 will read the token ID from the token and return this to the host system (operation 820). The read command from sector 5 is now repeated (not specifically shown in Figure 9), thereby allowing the boot code 521 to determine whether or not the data returned by the two successive read commands has toggled in value (operation 825). If so, this confirms that the boot program is communicating with USB emulation device 314 using FDU emulation, rather than a true FDU, as expected for the authentication procedure (otherwise the procedure may exit with an error). The boot program now reads the key from the token (operation 830), which is achieved by a read from sector 6 or 7, dependent upon the particular type of token (as indicated by its ID). The returned key can then be used to complete the authorisation process (operation 835). Note that there are a variety of ways in which the authorisation process can be completed. For example, in some embodiments, the USB authentication device 300 may be entirely responsible for the authorisation, in that it receives the authentication data from the device (e.g. in the form of biometric or token information), compares this to a set of locally stored authentication data, and then indicates to the host system whether or not the user is authorised in accordance with the outcome of this comparison. In other embodiments, the comparison operation and/or the stored authentication data may be located on some other system apart from the USB authentication device. For example, in one embodiment, the USB authentication device 300 may return the authentication data read from a token to the host system 410, and more particularly to secure disk drive 430. The data obtained from the authentication device can then be compared with authentication information held in key store 525 in order to determine whether or not the user is properly authorised (and is therefore entitled to access disk storage 530). The skilled person will be aware of various other approaches to complete the authentication, potentially involving multiple different forms or layers of authentication.

Figure 10 is a flowchart representing a summary of the operations of host system 410 and USB authentication device 300. Processing starts with an initial boot at the host system (operation 1010). During this boot procedure, the USB authentication device 300 is configured to emulate a floppy disk unit (operation 1020). As part of the boot procedure, the host system 410 communicates with the authentication device in order to perform an authentication or authorisation (operation 1030). From the perspective of the host system 410, these communications appear as if they are being conducted with a USB floppy disk unit, due to the emulation at the authentication device. It is now determined whether the authentication was successful (operation 1040). If so, the host system can continue operations as normal (operation 1050). This will generally involve completing the boot procedure, and then loading an operating system onto host system 410. Alternatively, if the authentication is unsuccessful, the system deprives the user of resources, depending upon the configuration. For example, the host system 410 may shut down completely if the authorisation fails (i.e. the boot process terminates), or the user may be restricted from accessing certain resources associated with the host system, such as secure hard disk drive 430, or perhaps a network service.

The procedure of Figure 10 therefore allows the authentication process to be performed by a USB attached device during the boot procedure, rather than having to wait until the operating system is loaded and running to provide full USB functionality. This approach is offers greater security than existing solutions, since the boot procedure is more difficult for an adversary to subvert than the operating system. In addition, access to the host system and its resources is controlled or restricted at the earliest possible stage of processing (i.e. immediately after power on).

Note that after the boot procedure has completed and the operating system has been loaded, the USB authentication device 300 may continue to emulate a USB floppy disk unit. Alternatively, the USB authentication device 300 may revert to a more standard form of USB device for authentication purposes (such as might be used by USB adapter 215 in the configuration of Figure 2), since the operating system will generally support the full range of USB devices (unlike BIOS code 421). One advantage of performing such a switch is that avoids the USB authentication device 300 subsequently appearing as a potential storage device to the operating system and hence to the user (who might otherwise perhaps try to save a file to it). The switch in (apparent) class of USB device for the USB authentication device 300 may be performed as part of operation 760 in Figure 7, since at this point it is known that the authentication has completed, or at any other suitable juncture.

The skilled person will be aware of many potential modifications on the approach described above. For example, although the USB device 300 of Figure 6 is based on authentication by token, it may instead perform some form of biometric authentication, for example based on fingerprints, or any other appropriate authentication process. In addition, the host system may require multiple different forms of authentication for any given user, such as a combination of a password and a token. This may lead to two or more USB attached authentication devices for a given host system (although a password would normally be entered via a keyboard rather than a specific authentication device). Note that if multiple authentication devices are utilised, these may each be provided with a separate USB emulation unit, or alternatively, two or more of the authentication devices might share a single USB emulation unit

In addition, although USB authentication device 300 emulates a floppy disk unit, other authentication devices might emulate other types of USB device - for example some other form of mass storage device. In general, the USB authentication device emulates a bootable device, in other words a device class from which host system 410 can potentially boot (typically a form of mass storage device). This is because BIOS code 421 normally includes USB support for bootable devices, since the BIOS code may need to access such a bootable device in order to complete the boot process - e.g. to load the operating system. In contrast, BIOS support for non-bootable device classes is very limited, and would not normally extend to authentication devices, since these are not expected to be bootable.

Note that a typical BIOS implementation might have USB support for a keyboard, since this could be used to configure the BIOS during the boot process. It is therefore feasible for the authentication device to emulate a USB keyboard rather than a mass storage device during the boot process, although in practice the functionality available in this mode is somewhat restricted (e.g. there is no facility to write to a keyboard).

It will also be appreciated that although boot program 521 from the secure har4 disk drive 430 invokes the authentication in the embodiment of Figure 5, in other embodiments the authentication could be initiated by the BIOS code 421 for the main host system 410 (for example in a system that did not include a secure hard disk drive), hi one possible implementation, the BIOS code 421 is configured to access a floppy disk drive (or other form of device emulated by the authentication device), and, depending upon the results of this access (i.e. the outcome of the authorisation), to then continue or terminate the boot procedure accordingly, hi another possible implementation, the BIOS code 421 is configured to load a boot program from the USB authentication device 300 itself, since from the perspective of BIOS code 421, USB authentication device 300 may appear as a FDU or other form of storage device for holding boot code. The boot program from the USB authentication device 300 may then be used to control the authorisation process. In conclusion, a variety of particular embodiments have been described in detail herein, but it will be appreciated that this is by way of exemplification only. The skilled person will be aware of many further potential modifications and adaptations that fall within the scope of the claimed invention and its equivalents.

Table 1

Claims

1. A method of authorising use of a computer, the method comprising: attaching a security device for authorising use of the computer to a USB interface of the computer via a USB adapter; initiating a boot program on the computer, wherein said boot program supports USB communications with a first device type; and communicating between the boot program and the security device via the USB adapter to authorise use of the computer, wherein the USB adapter emulates the first device type to the boot program during the communications.

2. The method of claim 1, wherein said first device type comprises a bootable device type.

3. The method of claim 2, wherein said first device type comprises a mass storage device type.

4. The method of claim 3, wherein said first device type comprises a floppy disk unit.

5. The method of claim 1, wherein said first device type comprises a keyboard.

6. The method of any preceding claim, wherein said USB adapter is integrated into the security device.

7. The method of any of claims 1 to 5, wherein said USB adapter is a separate device from the security device.

8. The method of any preceding claim, wherein said security device is used to perform a biometric authentication.

9. The method of any of claims 1 to 7, wherein said security device is used to perform an authorisation based on a token.

10. The method of any preceding claim, wherein the USB adapter stops emulating said first device type after the boot program on the computer has completed.

11. The method of any preceding claim, wherein the USB emulation supports a read command for the first device type to access the security device.

12. The method of claim 11 , wherein the USB emulation accesses the security device in response to a read command for the first device type directed to one or more predetermined sectors.

13. The method of claim 11 or 12, further comprising toggling data read from successive accesses to a fixed location of the security device.

14. The method of claim 13, wherein said toggling is only performed if said fixed location lies within one or more predetermined sectors.

15. The method of any of claims 11 to 14, wherein the USB emulation supports a write command for the first device type to access the security device.

16. The method of claim 15, wherein said write command can be used to specify a security setting associated with the security device.

17. The method of any preceding claim, wherein said computer includes a secure hard disk drive, and said boot program includes code invoked from said secure hard disk drive.

18. The method of any of claims 1 to 16, wherein said boot program includes code invoked from the security device using said USB communications.

19. Apparatus for authorising use of a computer comprising: means for attaching a security device for authorising use of the computer to a USB interface of the computer via a USB adapter; means for initiating a boot program on the computer, wherein said boot program supports USB communications with a first device type; and means for communicating between the boot program and the security device via the USB adapter to authorise use of the computer, wherein the USB adapter emulates the first device type to the boot program during the communications.

20. Apparatus comprising: a first interface for connecting to a USB host via a USB connector; a second interface for connecting to an authentication device; and a USB emulator linked to said first interface and to said second interface to serve as an intermediary for communications between the USB host and the authentication device, wherein said USB emulator is operable to emulate a BIOS- supported device with respect to the first interface.

21. The apparatus of claim 20, wherein said BIOS-supported device represents a bootable device.

22. The apparatus of claim 21, wherein said BIOS-supported device represents a mass storage device type.

23. The apparatus of claim 22, wherein said BIOS-supported device type represents a floppy disk unit.

24. The apparatus of claim 20, wherein said BIOS-supported device comprises a keyboard.

25. The apparatus of any of claims 20 to 24, wherein said authentication device is integrated into said apparatus.

26. The apparatus of any of claims 20 to 25, wherein said authentication device is used to perform a biometric authentication.

27. The apparatus of any of claims 20 to 25, wherein said authentication device is used to perform an authorisation based on a token.

28. The apparatus of any of claims 20 to 27, wherein the USB emulator is operable to stop emulating said first device type after a boot program on the USB host has completed.

29. The apparatus of any of claims 20 to 28, wherein the USB emulator supports a read command for the BIOS-supported device to access the authentication device.

30. The apparatus of claim 29, wherein the USB emulator is operable to access the authentication device in response to a read command for the BIOS-supported device directed to one or more predetermined sectors.

31. The apparatus of claim 29 or 30, wherein the USB emulator is further operable to toggle data read from successive accesses to a fixed location of the authentication device.

32. The apparatus of claim 31 , wherein said toggling is only performed if said fixed location lies within one or more predetermined sectors.

33. The apparatus of any of claims 29 to 32, wherein the USB emulator is operable to support a write command for the BIOS-supported device to access the authentication device.

34. The apparatus of claim 33, wherein said write command can be used to specify a security setting associated with the authentication device.

35. The apparatus of any of claims 20 to 34, further including boot code for invocation and execution by the USB host.

36. The apparatus of any of claims 30 to 35, wherein said apparatus is operable to connect to multiple authentication devices and to perform USB emulation for communications between the USB host and each of said multiple authentication devices.

37. A computer system comprising: a USB host; an authentication device; and a USB adapter including a first interface for connecting to the USB host via a USB connector; a second interface for connecting to the authentication device; and a USB emulator linked to said first interface and to said second interface to serve as an intermediary for communications between the USB host and the authentication device, wherein said USB emulator is operable to emulate a BIOS-supported device with respect to the first interface.

38. The computer system of claim 37, further comprising a secure hard disk drive that is only accessible following authorisation by said authentication device.

39. The computer system of claim 38, wherein said secure hard disk drive is part of the USB host.