Patent Application
20070300077
Embodiments of the invention are illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. It should be noted that references to “an” or “one” embodiment in this disclosure are not necessarily to the same embodiment, and such references mean “at least one.”
Computer system 110 conventionally includes components like those shown in the inset: a programmable processor or central processing unit (“CPU”) 111, memory 113, mass storage device 115, and hardware interface adapters 117 and 119. An operating system (“OS,” not indicated in this Figure) contains machine instructions to cause the programmable processor to perform operations as directed by a user of the system. It is frequently a responsibility of a service (like Winlogon service in the Windows™ OS by Microsoft Corporation of Redmond, Wash.) integrated with OS to identify the user and to prevent access by unauthorized individuals.
System 110 may communicate via a data network 160 (e.g. a local area network (“LAN”), wide area network (“WAN”), or similar distributed data network) with a remote system 170; as shown here, remote system 170 may provide a network authentication server 175 to assist the OS of system 110 in identifying users and controlling access.
After the primary user authentication, the user has established his identity to the computer and may use data and resources available under the applicable security conditions. Eventually, the user may launch a predetermined application (230), and the application may perform a secondary user authentication cycle. The secondary authentication cycle may be to prevent unauthorized use by an opportunist who comes upon the system while the authenticated user has stepped away momentarily, to establish a right to use a resource protected by an enhanced level of security, to identify the authorized user to a remote system from which data or service is sought, to gain enhanced privileges by legitimate system administrators and perform their administrative tasks or another similar purpose.
An embodiment of the invention detects that a process of interest is performing a secondary user authentication (240) and interposes a biometric data collection operation (250) to collect one or more measurements of a physical and/or behavioral characteristic of the user. For example, a fingerprint image, retinal image, hand geometry measurement, or voice impression may be obtained. In a preferred embodiment, keystroke timing measurements are collected while the user enters a string such as his name, password, or a common phrase in a login-like user interface window.
Next, the collected biometric data are validated (260) by comparing them against previously collected data stored on the server (or cached locally on the system) or local system, by transmitting the measurements to a remote authentication server or, in the case of an offline scenario, to a local service, or by another similar means. If the validation is successful (270), the embodiment may permit (or direct) the predetermined application to proceed with the user operation that triggered the secondary user authentication (280). If the validation is unsuccessful, the embodiment may permit the user to try to authenticate again by collecting (250) and validating (260) new biometric data.
Note that embodiments of the invention override or replace the legacy secondary user authentication procedure normally performed by the application. For example, an application might normally request that the user enter his password before continuing. An embodiment of the invention may collect biometric data instead of a password, or in addition to the password. In a system that uses keystroke timing measurements as a biometric data source, the timing measurements may be collected while the user types his password. Thus, an embodiment may use both legacy authentication data (the password) and biometric authentication data (the timings collected while the user types the password) to perform the secondary user authentication. However, when the application is permitted or directed to continue, the authentication has already been performed, so the application need not request that the user type his password again.
A first portion of this embodiment monitors active processes executing on the computer system (310). On Windows™, this monitoring can be accomplished with an operating system function called “EnumProcesses” (for “enumerate processes”). The embodiment can search the list of running processes for one (or more) that is running a program of interest. Programs of interest can be identified by names stored, for example, in a database or registry entry. If no process is running a program of interest (320), the embodiment simply continues to monitor active processes (310). If a process running a program of interest is detected (320), the embodiment determines how the program was invoked (330). For example, on Windows™, command line parameters may be displayed in the title bar of a user interface window presented by the program, so an embodiment can retrieve invocation information from the title of the window. Under other systems, command line parameters may be available through a programmatic interface to the environment of the process of interest. If some information about the program is unavailable, an embodiment can collect the information from the user (as described below). After collecting invocation information, the process is interrupted or terminated (340). On Windows™, this can be achieved by the “TerminateProcess” system function.
Next, the embodiment collects biometric data of the user (350). This may entail starting a new process to present a message or sequence of messages to the user, configuring and operating special measurement-collecting hardware, and so on. The biometric data collection process may also collect legacy authentication information such as a username or a password. At this time, any program invocation information that could not be automatically determined may also be collected from the user. After that, the collected biometric data is validated (360). Validation may also include checking legacy data (e.g. username and password) collected. If the validation is not successful (370), the collection and validation may be repeated until acceptable data is collected, or until a configurable maximum number of failures is reached. If the user is unable to validate successfully, he will be denied access to the program of interest.
If the validation is successful (370), the embodiment starts a new instance of the process with the program of interest (380), using the information collected earlier about how the program was invoked. In a preferred embodiment, the termination and restart procedure is transparent to the user: he will not notice that the program was stopped and restarted. For some programs, it may be possible to provide legacy authentication information through a command-line parameter or inter-process communication channel so that the program does not display a second (legacy) authentication dialog. Commonly-used programs on Microsoft Windows™ systems that are amenable to this approach include NET USE, which allows a user at one computer to access a resource of another computer; and RUNAS, which allows a user to start a program that will run as if it was started by a second user (often, the second user has greater privileges than the first user).
Embodiments can replace a legacy secondary authentication process of a program with a biometric authentication in another way. This will be described with reference to
First, this embodiment installs a global “hook” function that will be given the opportunity to observe and/or process messages between applications and the operating system (“OS”) (410). On Windows™, the “SetWindowsHookEx” function can install such a hook. The embodiment may contain a database or registry entry that holds the process names (like ‘xyzproc.exe’) and names of user interface windows (like ‘Enter network password’) that are of interest. Some embodiments may track individual fields within a user interface window to detect programs performing a secondary user authentication. For example, a text entry field named “Network Password” may indicate a secondary authentication in progress. In a Windows™ network environment, an Active Directory (“AD”) database or Structured Query Language (“SQL”) server database may be available to hold program, window, and field names of interest. When a new process is hooked (415), the embodiment reviews a database or registry entry listing of process names of interest. If the new process is not of interest (420), it is permitted to execute normally (425). If the new process is of interest (e.g. because it is known to perform secondary user authentications), then the embodiment performs a second review on database or registry entry of user interface window names. Once the user interface window name of interest is identified then the user interface window event messages are biometrically hooked and will be examined further. Alternatively, this user interface window can be hidden and physical biometric verification can be performed using fingerprint, voice, etc.
When a message is obtained by the hook function (430), it is examined to determine whether it is related to a secondary authentication process. If it is not (435), the message is forwarded to the program for normal processing (440). If the message is related to a secondary authentication (435), the embodiment collects biometric data (445) and validates the data (450), as in other embodiments. If the validation is not successful (445), the user may be permitted to try again.
If the validation is successful, the hooked program is permitted to continue. In some embodiments, the hook function's access to the program's message stream may be exploited to send synthetic messages or events to the program (460). These synthetic events may be useful to cause the program to operate as if it had performed the legacy secondary authentication.
For example, if the program normally creates a user interface window to prompt the user for a password, then collects keystrokes followed by a click of an “OK” button, the embodiment could hide the user interface window message and transmit a series of synthetic keystroke messages followed by an activation of the “OK” button to drive the program's logic through the legacy secondary authentication section and into the subsequent activities.
Note that similar hook capabilities are available in user interfaces and operating systems other than Microsoft Windows™, so embodiments of the invention can be applied in non-Windows environments. Some environments provide shared libraries or dynamically-loaded libraries (“DLLs”) that can be used to insert or interpose executable instructions to perform methods according to embodiments of the invention into existing programs' logic sequences. When a library overrides functions in this way, the overridden functions are said to be “shadowed.”
One difficulty that may be encountered in some embodiments that monitor active processes to detect programs that may perform secondary authentications is that such programs may execute so quickly that they are not detected. Indeed, a malicious user may prepare a batch file or use the aforementioned synthetic event facility to increase the likelihood of a program execution escaping the notice of the monitor (and consequently operating with less-secure, legacy, password-only authentication). To reduce the impact of such inadvertent or intentional rapid program execution, an embodiment may cooperate with a second logic module executing at a network authentication server. This is shown in
As mentioned earlier, some computer systems operate within a network, and some user authentication procedures may be performed by a remote system. For example, in Windows™ networks, a “domain controller” performs some authentication tasks. It may use Active Directory (“AD”) to store credential information and the Lightweight Directory Access Protocol (“LDAP”) to process authentication requests. A network authentication server such as an LDAP server or a domain controller may receive an authentication request from a client system (510), the request to include information such as the user's name and password. Normally, the password would be checked against a database and a “go/no-go” response returned to the client. However, according to an embodiment of the invention, the network authentication server may examine the request to determine whether it includes biometric data to identify the user (520) or through some biometric authentication modules running on the server confirm whether the user is already biometrically authenticated. If there is no such data (530), a “no-go” response may be returned (570) regardless of whether any password transmitted with the request is correct. If the request includes biometric data (530), the data may be validated (540) and a “go/no-go” response returned (560, 570) based on the result of the validation (550). Protocol requests and responses may be transmitted according to any format commonly accepted between client and server. LDAP is one widely-used protocol format.
Some embodiments may keep a cache of recent successful biometric authentications, either at the client system or at the authentication server. This cache may permit much of the processing described with reference to
Authentication server operations as shown in
An embodiment of the invention may be a machine-readable medium having stored thereon instructions which cause a programmable processor to perform operations as described above. In other embodiments, the operations might be performed by specific hardware components that contain hardwired logic. Those operations might alternatively be performed by any combination of programmed computer components and custom hardware components.
A machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer), including but not limited to Compact Disc Read-Only Memory (CD-ROM), Read-Only Memory (ROM), Random Access Memory (RAM), and Erasable Programmable Read-Only Memory (EPROM).
The applications of the present invention have been described largely by reference to specific examples and in terms of particular allocations of functionality to certain hardware and/or software components. However, those of skill in the art will recognize that biometric verification of secondary authentications can also be produced by software and hardware that distribute the functions of embodiments of this invention differently than herein described. Such variations and implementations are understood to be captured according to the following claims.
