WO2003093923A2

WO2003093923A2 - System and apparatus for authenticating to a system or network

Info

Publication number: WO2003093923A2
Application number: PCT/IB2003/003301
Authority: WO
Inventors: Robert Eryou; Clovis Najm
Original assignee: Robert Eryou; Clovis Najm
Priority date: 2002-04-30
Filing date: 2003-04-30
Publication date: 2003-11-13
Also published as: EP1506469A2; CA2483989A1; CA2483989C; WO2003093923A3; AU2003247117B2; AU2003247117A1

Abstract

A mobile biometric device, or biotoken and server are disclosed that permit biometric validation of a person that has initialized the biotoken and has communicated one or more codes generated by the biotoken to a server over either a secure or unsecure communications channel. The biotoken that includes a means for capturing biometric information, for hashing some portion of information, and for transmitting or displaying a code that is calculated using a clock value, a random number, a secure hash function and a counter. The server includes functions for initializing the biometric device, for storing key values responsive to initialization, and for validating codes that are provided responsive to future use of the biometric device following a request for validation. Additional functions and features are also disclosed for creating a secure, auditable and private application space on a device or machine, such as a computer or cell phone.

Description

System and Apparatus for Authenticating to a System or

Network

Field of the Invention

This invention relates primarily to the field of system authentication and related identification devices. More specifically, this invention relates to a system and method for providing a link between an identity on a network and one or more pieces of biometric data associated with that identity and a method for securing transmitting such information over an information network.

Background of the Invention

Internetworks of the future will allow and promote universal access. Users will be able to access the network at a multitude of access points separated by significant geographic distance and many administrative boundaries. This phenomenon has introduced new security issues compared to the traditional fixed networks. This is mostly because of the lack of physical protection of the mobile network access points and transmission of the information using radio or other forms of communication.

In the normal networking environment, security is established when a person and a system create a shared key, such as a password, that is used to "identify" the person as a user on the network and to enable privileges accordingly. Unfortunately, many programs (and good guesses) provide unauthorized parties, such as computer hackers and the like, the ability to attempt an unlimited number of log-in attempts which will eventually crack such a simplistic system. This presents a significant security concern.

New technologies have been developed to resolve this difficult but each presents security holes that create significant difficulties and defeat any attempts at "real" security. For example, one company has developed a device that receives a new code after a fixed period of time that must be used to log in to a network. While this approach does reduce the probability that a hacker will "crack" the code without the device, a loss or theft of the device immediately gets around such protections, hi other words, the security is effectively a possession-based level of security — as long as an authorized person possesses the token, the network (or system) is secure. Additionally, these sort of devices rely upon the server and device being synchronized and in many cases these devices will get out of synch. This means that the code entered by the user will not be shred by the system or network and will be rejected.

Another approach to the security problem has been provided by biometric authentication systems, h such a system, biometric data from a person, such as a thumb print, a retinal scan, a hand print, face shape, etc. is stored in a database. Later, when a person wished to be authorized, a scan of some type is performed and the stored data and captured data are compared. This solution has many problems that include: 1) a scanner of the biometric data must be provided at each entry point; 2) the data must be stored on a central database; and 3) the person many not wish to have such sensitive data stored across many servers for each authentication system.

A similar problem is evident with credit cards and similar "ID cards" that provide a link between a piece of plastic and a financial account, i such instances, a person that has stolen the card can often use it without restriction by faking the person's signature (although rarely confirmed anyway) until the card is reported as lost or stolen. Indeed, when purchasing products online, it is often the case that a signature is not even required as the data from the card is entered on an electronic form without any other corresponding code or ID.

What is needed, then, is an authentication system that does not require specialized hardware or scanning equipment, that stays synchronized with a central server, that does not require centralized storage of each person's biometric data, and yet still uses biometric data (rather than simple possession) to authenticate a person to their identity.

Summary of the Invention

The present invention provides such a system and method. The system of the present invention is comprised of two primary components: an authentication server and a biometric capture device (hereinafter referred to as a "biotoken"). The biotoken is comprised of a biometric capture system (such as a fingerprint scanner, a retinal scanner, DNA scan, or similar devices) that stores biometric information and can later be used to verify biometric (or other unique) input by comparing the captured biometric data with the stored biometric data. In the preferred embodiment, the biometric capture device is a fingerprint scanner and the biometric information (or an encryption of hashed value of such information) is stored in either RAM or ROM on the device. Additionally, the biometric information may be the actual information or may instead be a template of the biometric information. This might include, by way of example, a scan of discreet "data points" on a fingerprint rather than storing all points (such as an image or other data file) of the fingerprint. The biotoken also includes a display and/or transmitter for transmitting i the first step, the biotoken must be initialized. As will be further described herein in greater detail than required for enablement, the biotoken begins an initialization process that begins with the capture of one or more pieces of information unique to a person, such as biometric information. For example, biometric information, such as a fingerprint scan, could be captured. This information need only be stored on the device. While it could also be stored on a central server, such storage is not required and such an approach faces significant drawbacks (although such approaches could represent a simplification of the present invention). hi the next step, the biotoken begins a process of exchange whereby the biotoken downloads, updates, or verifies a unique certificate or identifier that can be stored on the biotoken. This certificate or identifier can be used to communicate a log-in or other password that can be used to authenticate a person to any electronic system (or related peripherals). For example, this could download a private certificate, such as those offered by Verisign, Certicom, and other companies, that could be used to "sign" any "passwords" being communicated. In such a system, the authenticating server could verify the identity of the token by using the corresponding public key. Alternatively, "manual" entry could be used whereby the password or identifier is entered directly into the system or input using distance transmission methods (such as RF, bluetooth, wireless, and others) without use of a certificate.

For example, one embodiment could include a fingerprint scanner, digital certificate, and a number generator or receiver. In the case of a receiver, the token could receive a new password or ID every fixed (or variable) time interval that could only be displayed or transmitted responsive to proper biometric authentication. Authentication would be achieved by comparing the captured biometric value(s) with the stored biometric value(s). Once authentication has occurred, the password or ID could be displayed or transmitted (or both) as configured. This could include a fixed password or ID, or any other form of variable or adjustable password or ID wherein the method and variables used to generate such adjustable passwords or IDs are shared so that each side can compare the received password or ID with the password or ID stored on the server. Again, in the simplest case, a variable password or ID could be adjusted by generating a new number after a certain time interval has passed. As long as the server and biotoken have a means for sharing such a fixed number (a process which is well-known and understood), the authentication step could be easily implemented.

This is but one embodiment. The preferred embodiment of the invention is a far more secure approach that provides even more substantial improvements over any prior art. It includes two additional components. First, an encryption methodology is provided that enables an extraordinarily secure manner of generating a password or code dynamically that would prevent a hacker from making a guess about the next password or ID even if they knew of every password or ID that had come before it. This approach represents a fundamental improvement in a manner in which data is encrypted prior to being communicated to another system and specifically provides a block to two common security attacks (as further described below). An extension of this security improves the server such that the server itself is not subject to being corrupted in a way that would enable a rogue server to fake "authenticating" a token that should not be authenticated.

Second, a methodology for transferring the information over a network such the password or ID is not intercepted or otherwise manipulated in a way that allows a third party to use the captured data to enable them to use the password or ID for malicious purposes. This is crucial in an environment where the step of authentication travels over unprotected public networks or where the server itself transmits sensitive data back to the token, such as a private certificate. The protocol of the preferred embodiment is called DCTP — digital certificate transfer protocol. This protocol can be used to transmit a private digital certificate (or any sensitive data or key) to a machine or system such that, once a person has been properly authenticated, can be used to sign documents, receive applications, execute transactions, or perform other actions as may be enabled by the system on to which the private certificate (or data) has been transmitted.

Each of these pieces, both together and independently, represent important new systems for managing personal identities, providing authentication, and creating an audit trail such that fraud and other forms of malicious or irregular activities cannot be perpetrated on the secure system. The systems can be used to protected data, to protect financial accounts, to protect national secrets, to protect physical facilities (such as airports), to protect computer networks, to enable access to public goods, and even to slow efforts by terrorist (and other targets of homeland security) and other illegal elements that might otherwise have free run and access to important resources. It is for this reason that the applicants urge expedient review and approval of these inventions for patenting.

Brief Description of the Figures

Figure 1 is a block diagram of one embodiment of the biotoken;

Figure 2 is a high level architecture of one embodiment of the authentication server;

Figure 3 is a block diagram of the CAS LDAP Proxy;

Figure 4 is a block diagram of the CAS engine;

Figure 5 is a block diagram of the CAS GTNA;

Figure 6 is a block diagram of the CAS Admin/Enrollment module of the CAS Server;

Figure 7 is a block diagram of the CAS SDK used by the CAS Server;

Figure 8 is a block diagram of the Crypto-Proxy module of the CAS server;

Figure 9 is one example of the deployment architecture for the CAS server;

Figure 10 is an alternative sample deployment architecture for the CAS server;

Figure 11 is a flowchart illustrating one method for initializing the biotoken; , Figure 12 is a flowchart illustrating biotoken validation;

Figure 13 is a flowchart illustrating one embodiment of the digital certificate transfer protocol; and

Figure 14 is a flowchart illustrating another embodiment of the digital certificate transfer protocol.

Detailed Description of the Preferred Embodiment(s)

The following description provides a description of several distinct inventions, h the preferred system, each of these components is used and applied to provide a distinctly secure process for identifying, authenticating, enabling, and auditing one or more individuals on or to a system. While much of this description will include references to this combined system, each component may also be used individually and it is the expectation of the applicants that such components will be used in a number of difference environments in this manner. As such, the scope of the claims should not be interpreted to require such related but distinct components. Additionally, while this invention will often make use to biometric identification, any other form of identification could be used. For example, a chip or other electronics could be embedded under a human's skin and used to provide a unique identifier for such person. In the case of animals, this could include a tag or other form of ID on the ear, for example.

Certain terms will be used throughout this description. They include:

CAS The Authentication Server

DCTP Digital Certificate Transfer

Protocol

SDK Software Development Kit

GΓNA Graphical Interface for Network

Authentication

JNDI Java Naming and Directory

Interface

LDAP Light-weight directory access protocol

DLL Dynamic Link Library

h the simplest embodiment of the present invention, a system and method is provided for authenticating an individual to a network through a network device. This is achieved by having a hidden rotating password, or ever changing challenge phrase, that is only displayed when biometric information scanned by a device or token is identical to one or more stored biometric profiles that were created upon initialization. Upon authentication of the biometric identity, a number or challenge phrase appears. The number or challenge phrase is then entered into a network access device or other system by manual entry, such as a keypad, or through another communications interface, such as radio frequency, bluetooth, or other forms of wireless communications. Once the challenge phrase, ID or password has been entered into the network access device, it is communicated to the server. This can be accomplished via several means such as an encrypted channel over a public network, a dedicated network connection or, if less secure means are acceptable, over any public computer network. Responsive to authentication by the server, the authenticating device (either the token itself or the network access device) is then transferred their online identity, such as a digital certificate, or other data such as a unique encryption key that can be used to perform various actions that are only authorized by the identity that is connected to the token. h contrast with the prior art, where biometric security systems are constrained to a single system with a connected reader or scanner, the present invention provides a portable biometric scanner that can be adapted for any system. For example, many people use key cards to open secured areas, such as offices or research labs. Clearly, another person could easily take and use the card to get into the facility. By adding an extra field that can be received and transmitted by the key card reader, however, the present invention could be adapted to include an RF transmitter and could transmit the number for use with the existing door panels (or at least added as an additional peripheral) thereby permitting the same device to be used for a computer network as a perimeter security device. This means that either approach could be used without needed to completely replace the prior system. This is particularly try in setting where significant investments may have already been made but the existing security is no longer as secure as it needs to be, such as at airports.

A similar benefit is accomplished when using the system on a computer network. Rather than having a password, a registered user could either enter the number manually into the log-in screen or could use peripheral technologies, such as a USB cradle or wireless transmitter, to transmit the number and authenticate the user.

Perhaps the most important benefit of this approach, however, is the fact that a user's privacy is maintained. One of the reasons that there has been great resistance to biometric devices is the sense that your very tissue and DNA is being taken. Assuming that becomes the main ID, identity theft could take on horrific proportions with private companies and other commercial entities storing and manipulating such information. In contrast, the present system stores the biometric information in only one place and that information is never shared with another person (or a server), hi other words, in contrast to most solutions, the present system provides security without infringing the privacy of its users.

Referring now to Figure 1, a block diagram of a biometric device or biotoken is shown, hi this embodiment, the biotoken includes ROM 105, a scanner 110, transmitter 115, processor 120, and secondary memory 125, such as RAM, and an LCD screen 130. i the illustrated embodiment, the ROM 105 is used to store a shared secret, a fingerprint template, or both. The scanner 110 is used to scan a fingerprint and create a "template" or image of the captured finge rint. This information is collected during initialization and is used to compate during the verification process (each as further described below). The transmitter 115 is used to transmit the "biocode" or password that will be used to authenticate the person to a system running (or otherwise connected to) the CAS server. The processor 120 is used to generate the code based on an initialization and verification process and may also be used to apply secondary authentication means, such as a PKI certificate.

Referring now to Figure 2, a high-level block diagram of the Authentication Server is shown. Each of these components is described in further detail below h the illustrated embodiment, the CAS Server 205 includes both a CAS-Engine 305 (see Fig. 3) and LDAP proxy 310 (see Fig. 3) that are hosted on one physical machine, such as a computer server. The User profile & Key store 210 could be unique or could be a 3rd party LDAP server (such as Microsoft Active Directory or fPlanet Directory Server 5.1). The CAS-Admin & CAS -Enrollment module 215 is preferably an independent web-based application, which can be hosted independently on separate application severs or may be on different machines. CAS-GINA module 220 is preferably deployed on end-user machines, such as a windows desktop 260, and enables end user support for the BioToken authentication. The Crypto-proxy 225 will also be preferably installed on end-user machines and the applications on the end user machine, like an email client 250, will preferably be configured use this proxy. A Crypto-browser 225 could also be provided and is preferably a signed-applet that gets downloaded on client's browser to enable the digital certificate transfer process (DCTP), such as the transfer of a key from a public key respository 240. The CAS- SDK can be used by 3rd party applications to integrate BioToken Based authentication and support for DCTP protocol.

Authentication Server (CAS)

Referring now to Figure 3, in the preferred embodiment of the present invention, the authentication server of the present invention consists of two modules CAS-Engine

305 and CAS-LDAP-Proxy 310.

CAS-Engine 305

The CAS-Engine 305 is preferably implemented using a "global" language that is supported on multiple platforms, such as Java, and includes the BioToken Verification

Process. The CAS-Engine 305 will also preferably include the DCTP functionality. When in operation, the CAS-Engine 305 can use a database, scuh asn an LDAP Server, for storing the user profile along with BioToken information, groups, rules/policies and key-split files. Alternatively, the Key-Split files may be stored in a separate common LDAP server, h the preferred embodiment, the LDAP server will be accessed using standard vendor independent APIs like JNDI. In the java-based implementation, the protocol of communication between LDAP Proxy 310 and CAS- Engine 305 will be a direct java call. CAS-Engine 305 can also be configured to support the searching of remote LDAP servers for user's public-keys. Referring now to Figure 4, a block diagram of a sample embodiment of the CAS- Engine 305 is provided. As illustrated, the CAS-Engine 305 can be further broken down into following sub-modules

CAS-Engine Handler 405 - This handler 405 is a protocol mapper component, which converts the requests from external components to CAS-Engine method calls. The external component in this case is CAS-LDAP-Proxy. The communication between the external component and CAS-Engine could be direct java call or RMI or could be anything. CAS-Engine is preferably made protocol independent in such a way that, if another protocol other than the LDAP/S protocol, such as HTTP/S or wireless access protocol (WAP) needs to be supported, only the CAS-LDAP-Proxy need be replaced with appropriate protocol proxy server.

Admin Functionality 410- This sub module 410 will preferably handle all the admin functionality that CAS needs to support.

BioToken Functionality 415- This sub module 415 will preferably handle BioToken verification, initialization and resynchronization functionality. This functionality is further explained below with reference to Figure X.

DCTP Functionality 420- This sub module 420 will preferably handle the DCTP functionality. This functionality is further explained below with reference to Figure X.

Crypto Toolkit Facade 425 - This sub module is used to decouple the above 3 modules from the underlying Crypto toolkit used. This sub module would preferably allow the replacement underlying toolkit, if required, without affecting the core engine implementation.

Helper Classes 430 - These are set of Java Helper classes for Logging, debugging, configuration and some conversions functions required for normal operation of the CAS-Engine 310. Repository Layer 435 - The repository layer 435 will allow the changing of underlying repository (like RDBMS/File/LDAP) configutation will preferably use standard Java APIs like JDBC/JNDI. This module 435 will also handle connection pooling, interfacing with multiple repository, etc. This layer 435 will also preferably handle the extensibility requirements of supporting different types of repository from different vendors. CAS-LDAP-Proxy 310

The CAS-LDAP-Proxy 310 is preferably an LDAP/S protocol compliant proxy that is a front-end listener and communicates with clients that communicate using LDAP protocols. For example, this proxy would be responsible for accepting requests from the CAS Server 205. The CAS-LDAP Proxy 305 and CAS-Engine 310 are preferably running on a single physical machine. This proxy 310 does not need to implement relaying of requests to 3rd party LDAP Servers will preferably only service requests that are meant for CAS-Engine 310.

i operation, CAS LDAP Proxy 310 listens to the client requests on a particular port (or ports) that has been configured. For example, this port could be provided in an XML file. The proxy 310 will listen to the requests on two separate ports, one port for the requests in normal mode (i.e. standard LDAP requests) and the other port is for the requests in SSL [LDAPS requests] mode. The CAS-LDAP-Proxy 310 would also preferably be configured to communicate with CAS-ENGINE 305 over different communication channels ( such as Direct Java Call and RMI). This configuration information may also be read from the XML based configuration file.

Referring again to Figure 3, a block diagram illustrating the CAS-LDAP- Proxy 310 is provided. As is well-understood in the art, the proxy 310 will have different backend implementations depending on the manner in which data is stored and retrieved. For example, BackendJDBC could interface with RDBMS over JDBC for storage/retrieval of data, hi the ullustrated embodiment, a backend, called BackendCAS 312, does the interfacing with CAS-ENGINE 305.

The BackendCAS 312 will get handle to CASEngineHandler interface 320. The CASEngineHandler 320 will have different implementations depending upon communication channel between BackendCAS 312 and the CAS-Engine 305. For example, the implementation could include a CASEngineHandler npl 325 for direct java call and CASEngineHandlerRMI 330 for RMI communication. The BackendCAS 312 will get the handle to CASEngineHandler interface 320 from a class that uses the CASEngineLookup interface 314. In the preferred embodiment, different implementations of CASEngineLookup interface 314 can be registered with BackendCAS 312 depending on the communication mechanism between CAS-ENGINE 305and CAS-LDAP-Proxy 310. For example, if the communication between CAS-ENGINE 305 and CAS-LDAP-Proxy 310 is direct java call, there will be CASEngineLookuphiipl (not shown) which implements and inside the implementation of getCASEngineHandler () function and will return an instance of CASEngineHandlerlmpl class 325. Similarly if it's RMI, the implementation CASEngineLookupRMI (not shown) could perform an RMI lookup and get handle to CASEngineHandlerRMI object 330.

With the above architecture, the CAS-LDAP-Proxy 305 and CAS-ENGINE 310 are decoupled in such a way that communication channel between them can be changed to anything by having different implementations of CASEngineHandler Interface 320 and changing the getCASEngineHandler () function implementation, thus giving the several deployment options for CAS-Engine 305 and CAS-LDAP- Proxy 310. CAS-GINA

The next component in the authentication system is CAS-GINA 220. In the preferred embodiment, this component 220 is a Windows GINA module that is used for Windows desktop users to authenticate using BioToken based authentication. This module 220 could be developed as a pass-thru GINA stub.

In operation, this module 220 will accept the BioToken code from the user and will open a secure communication channel 260 with CAS server 205 during verification, hi the illustrated example, the CAS-GINA 220 is using LDAPS for creating a secure channel 260. A windows logon dialog box can be provided and customized to accept Windows userid, Windows domain password as well as the BioToken code. The Network (Windows, Netware, etc.) username and domain password will also preferably be passed to MSGINA or another 3rd party (i.e. GINA chaining) GINA to complete the Network (Windows, Netware, etc.) authentication.

Referring not to Figure 5, a block diagram of one embodiment of the CAS- GINA module 220 is shown. In the preferred embodiment, the CAS-GINA module 220 will consist of 3 sub modules: Winlogon functions 510, helper and utility functions 520 and the GUI module 530. The WinLogon function 510 preferably includes a sub module that contains the implementation of all the functions that are required by GINA module 220. The GUI module 530 preferably consists of customized screens that replace the Windows standard GUI interface. The GUI module 520 can also be extended to support reading of Biotoken code (or Biocode) from hardware, such as a cradle or RF receiver, instead of manual user input. The Helper and Utility functions 520 can be used to readwrite the configuration entries from registry, log the debug messages, and perform other administrative functions.

Some of the WinLogon functions 510 that could be implemented are describee below:

WlxLoggedOutSAS() - This function coul be invoked by the winlogon process whenever it detects a SAS and no user is logged in. A customized logon screen is displayed to the user instead of the standard windows logon screen. This screen prompts the user to enter his network username, network password, and BioCode and domain name if the machine is on a domain. The network username and the BioCode are passed to the CAS-LDAP-proxy and the user is authenticated by BioToken methods. On successful authentication the network username and the network password is passed to the default MSGINA or to any 3rd party GINA component for windows network authentication thus supporting forwarding chaining of GTNA modules.

WlxWkstaLockedSASO - This function could be invoked by winlogon process whenever it detects a SAS and the user has logged in and tries to unlock a locked terminal. A customized screen as explained in WlxLoggedOutSAS is displayed to the user and the user enters his network username, network password and BioCode and these (excluding network password) are passed to CAS-LDAP-proxy. On successful authentication the control is passed to the 3rd party GINA component thus supporting forward chaining, h case of any network problems the user has an option to logon locally to his machine without performing any BioCode authentication.

Some of the GUI Module functions 530 that could be provided include: DisplayCustomisedLogonBox() - This function could be called from WlxLoggedOutSAS and WlxWkstaLockedSAS. This function displays the customized windows logon box. The customized logon box prompts the user to enter his network username, network password, and BioCode and domain name if the machine is on a domain. The user is also given an option to locally logon to his machine in case of any network problems. In case of user choosing the local logon option BioCode authentication is not done for him. The network username and the network password are passed to MSGINA for windows network authentication. Some of the Helper and Utility Module functions that could be provided include: GetCurrentGTNAO - This function could check for any previous GTNA entry in the registry and retrieve its path to perform the forward chaining. BioTokenAuthenticationQ - This function could be called from within DisplayCustomisedLogonBox. The main purpose of this function would be to make a connection with the CAS-LDAP-proxy 310 and pass the network username and the BioCode. It gets a success or a failure response from the CAS-LDAP-proxy 310 depending on the authenticity of the user. This function is a part of CAS-SDK 230. Set Auto Admin() - This function could be called from within WlxWkstaLockedSAS and WlxLoggedOutSAS. The main purpose is to make an entry in the registry thereby informing the windows that a logon box has been displayed to the user and there is no need for the windows to display its traditional logon box to the user. SetAutoCredentials() - This function could be called from within WlxWkstaLockedSAS and WlxLoggedOutSAS. This function would preferably write the network username, network password and the domain name if any in the registry for MSGINA to carry out windows network authentication. GetPrevNamePassword() - This function could be called from DisplayCustomisedLogonBox function. This function preferably calls the read registry functions and gets the previously logged in username and password and returns these details to the calling function. The calling function uses these details and sets them in the text box. The password read from the registry is encrypted and this function calls the decrypt password function before returning the password to the calling function.

PutPrevNamePassword() - This function could be called from WlxLoggedOutSAS function. After successful logging in of the user and before exiting from WlxLoggedOutSAS function the PutPrevNamePassword is called. The usemame and the password is passed to this function and this function calls the write registry functions and makes the corresponding entry in the registry. This function calls encrypt password before writing it on to the registry.

EncryptPasswordO - This function could be used to encrypt the password before storing in the registry. The function used to store the value is called from PutPrevNamePassword. DecryptPassword() - This function could be called from GetPrevNamePassword function. This function is preferably used to decrypt the encrypted password. ReadConfiguration() - This function could be called from the main program and reads anything that has to be read from the configuration. GenerateKey() - This function could be called from EncryptPassword and DecryptPassword function. This function preferably gets the username or userid from the calling function and generates a symmetric key based on the userid or username. The symmetric key is returned to the calling function. CAS-Enrollment

This is a Web based application developed in JSP/Servlet to do the Self- Service of user's and CryptoLex BioToken initialization. This module will accept the user initialization string and write to directory for future BioToken verification process by making use of CAS-SDK.

The functionality required in this Web Interface for BioToken initialization is simple, it just needs to validate the user against the 3rd party LDAP using standard userid-password based authentication first, then take the users BioToken initialization string(4 x 8 chars) and send it to CAS Server for storing them into the repository for future BioToken/BioCode verification. The self-service functionality will support user registration, forgot password and change-password features.

The CAS-SDK interface can be segregated into Admin, BioToken and DCTP related APIs. The CAS-SDK implementation will make use of Crypto Toolkit facade to decouple the implementation from underlying toolkit used. The Communication layer will handle the protocol specific functionality that is required based on underlying protocol used. The Communication layer will be designed and implemented in such a way that it can made as a pluggable module, allowing usage of different implementation of communications layer to support different protocol. CAS-Admin

Referring now to Figure 6, a block diagram of one embodiment of the CAS admin module 410 is shown. In the preferred embodiment, the CAS admin module 410 is a web based application developed in JSP/Servlet. It would ideally handle the CAS user management, group management, Crypto-proxy/Crypto-browser rule management and activity reporting. The user, group and rule management functions would preferably include create, delete, search, association and update. The CAS- Admin 410could also have an interface for managing the Policies/Rules of Crypto- proxy/Crypto-browser centrally and assigning these Policies/Rules to the users or groups.

The CAS-ADMIN and CAS-ENROLLMENT modules 410 illustrated are preferably developed in HTML/JSP and may also be purely based on Java to insure platform independence. The primary blocks of the CAS admin module 410 are further described below.

Presentation Layer 605- This layer 605 contains the HTML/JSPs and javascript functions. The responsibility of this layer 605 is to display the end-user GUI interface, accept and validate user inputs and then submit the data in the form of HTML forms to controller layer.

Controller Layer 610 - The controller layer 610 responsibility is to extract the data submitted, convert it into format wrapper classes 615 accept and call appropriate wrapper class functions 620. In the preferred embodiment, there would be separate controller JSP for each functionality, such user management, group management, management reporting, and related functions.

Wrapper Classes 615 and Utility Functions 620 - In the preferred embodiment, the wrapper classes 615 are the pure Java classes that handle the communication to and from CAS-SDK layer 230. These classes 615 are used by both presentation layer 605 and controller layer 610 JSPs. The utility functions 610 would include more basic utilities such as data conversion, data extraction and logging functions. CAS- SDK 230

Referring now to Figure 7, a sample embodiment of the CAS SDK 230 is shown. This SDK 230 is used to integrate the 3rd party applications to support BioToken based authentication. This SDK 230 will preferably be developed in C++ and Java so that it is supported on many hardware platforms. The functionalities of this SDK 230 are Biotoken verification 710, administration and enrollment 720 and support DCTP protocol 730. The other modules like CAS-GINA 220, Crypto-proxy 225, Crypto- browser 225, CAS-ENROLLMENT/CAS-ADMIN 215 will make use of CAS-SDK 230 for all their communication with CAS-ENGINE 305. Crypto-Proxy Module & Crypto-browser

Referring now to Figure 8, a sample crypto-proxy 225 is shown. The crypto- proxy 225 is the proxy that will be installed on a client desktop. The Crypto-proxy 225 will be "application-protocol aware". In other words, based on the application protocol and Policies/Rules defined, it will do the necessary operations (such as digitallly signing documents, network authentication, encryption, etc) to the application protocol headers and/or payload. In the preferred embodiment, the crypto-proxy meets the OpenPGP specification via the OpenPGP Handler 820. The Protocols that Crypto-proxy can support include HTTP 802, IMAP 808, POP3 806 and SMTP 804. With this flexibile system design, additional protocols can be supported with minimum effort. The Crypto-proxy will also support the forwarding of BioCode along with password to the protocol-server for authentication. The Crypto-proxy 225 will ideally be compatible with most of the standard web-browsers and email clients.

The CAS SDK 230 will be used by the crypto-proxy 225 for authentication and downloading the key. The crypto proxy 225 will preferably use LDAP/S protocol while communicating with CAS Server 205 for authentication, retrieving Policies/Rules and downloading of key.

The Crypto-Browser 225 is preferably designed to act as a browser Java applet that employs the same functionality as the Crypto-Proxy 225 on HTTP/HTML GET/POST actions. This would provide a secure browsing interface.

As further illustrated in Figure 8, the Crypto-proxy module 225 will consists of following sub modules:

BioToken Input Handler 810 - This module 810 will take care of the capturing of the user's userid and BioCode. In the preferred implementation, a Java based GUI can be used to capture this information. However, other methods of capturing the BioCode can be integrated by reimplementing this module alone.

Configuration Handler 815- This module 815 will preferably take care of capturing and reading all the configuration entries required by the Crypto-proxy module 225. BioToken Verifier 825- This sub module 825 will handle the verification of BioToken either through CAS-SDK 230 or pass-through to remote server. DCTP Handler 830- This sub module 830 will preferably handle the DCTP functionality by making use of CAS-SDK 230.

Rule Handler 840- This sub module 840 will preferably parse the XML file downloaded from CAS server 205 and will determine the decision on the operation that needs to be done for a particular protocol and user. Private-Key Store 850- This sub module 850 will preferably take care of reading/storing the private key in memory securely. OpenPGP Handler 820 - This sub module 820 will preferably do all the necessary operations for supporting PGP-like functionality such as signing, encrypting, generating headers, in each case according to OpenPGP specification. This module will make use of Crypto toolkit facade 860 to do the above operations. Protocol Handler 870- This sub module 870, along with the OpenPGP handler module 820, will take care of adding new protocols that can support in the secure proxy seamlessly.

In the preferred embodiment, the present system is implemented in a manner that is scalable, fail safe and efficient. A sample system embodiment of the CAS system is illustrated in Figure 9. The benefits of illustrated deployment of the CAS server and preferred characteristics of such a system will be described below. Load Balancing

The CAS system architecture can be implemented in a highly scalable and robust by providing load-balancing mechanisms 910,920 at all tiers of the architecture, preferably using a combination of hardware- and software load- balancing. CAS Server

Load-balancing 910 at the CAS server tier 930 is preferably implemented using a hardware load-balancer that distributes incoming LDAP requests to a cluster of identical CAS servers 205. Alternatively, a round-robin DNS load-balancing can be implemented to distribute requests to the CAS server tier 930. However, a hardware load-balancer provides additional robustness and flexibility in the load-balancing mechanism and is preferred. LDAP

Load-balancing 920 and scalability at the database tier 940 is preferably implemented using clustering mechanism. Having multi-master replication in a server cluster 950 provides a high level of scalability at the LDAP directory server tier 960. Redundancy

The illustrated architecture of the CAS provides a high level of redundancy at all tiers 930, 940, 960 eliminating single-point-of-failure and thus ensures a high availability in mission-critical implementations. In such an implementation, all tiers 930, 940, 960 of the architecture can gracefully handle failure of individual applications or server hardware without interruption of service. Server Failure

If CAS server 205 fails due to hardware or software failure, the hardware load- balancer 910 will notice the failure when trying to dispatch incoming CAS requests to the CAS server 205. The load balancer 910 will mark the server 205 as unavailable and will redirect the request to other CAS servers. Since each CAS Engine 305 running on a server 205 has access to same data, any CAS server 205 available can handle requests. Thus, users will not be affected by CAS server 205 failure. LDAP Failure hi the preferred embodiment, the LDAP directory servers 950 would also provide hot-failover mechanisms and Multiple-Master replication as well as Master- Slave replication to guarantee uninterrupted service in case of a hardware or software failure.

Multi-master replication allows a subtree of LDAP entries to be mastered by more than one Directory Server; that is, each master server can accept updates for entries within a replicated subtree. Each master can replicate add, delete, modify, and rename operations to the other master and to multiple slave servers. The replication process used between one master and another is the same as that used between a master and a slave. If one master is unreachable for some period of time (due to hardware failure, software failure, or network failure), the other master continues to accept updates and can replicate the changes to the read-only replicas. A load balancing hardware 920, or a Directory Access Router can be placed in front of the master servers 950 to facilitate smooth fail-over. Platform Independency

The CAS system architecture can be implemented for maximum platform neutrality by using platform-independent language and supporting industry standard protocols for seamless interoperability. The following provide variations or components that may be used to maximize interoperability. Operating System

In the preferred embodiment, most of the components can be built using the Java programming language. In such a case, the CAS 205 can be deployed on any operating system supporting the Java platform. LDAP Server

The CAS 205can use standard LDAP v3 for accessing user records and other information stored in any Directory server conforming to the LDAP standard.

An alternate embodiment of the CAS system is illustrated in Figure 10. In the illustrated deployment, the CAS-LDAP-Proxy 310 and CAS-Engine 305 are separated and are deployed on different physical machines 1005, 1010, 1015, 1020, 1025, 1030. In this embodiment, the communication channel(s) between CAS-LDAP-Proxy 1005, 1010, 1015, 1020, 1025 and CAS-Engine 1030 is based on RMI. In this scenario, several CAS-LDAP-Proxies 1005, 1010, 1015, 1020, 1025 clustered together communicate with a single CAS-Engine 1030 instance on a separate physical machine. This deployment also has same characteristics as the deployment described above with reference to Figure 9, however this approach gives administrator more flexibility in terms of deployment.

The combination of the biotoken and the CAS system described above represent a substantial improvement in the security of such processes. In order to provide even greater security, however, the system may also use the following secure method for initializing and operation the biotoken. A brief background on some basic encryption building blocks is provided.

At the most fundmental level, the entire system is premised on a need for entity authentication. Entity Authentication is the technique to allow one party, the verifier, to gain assurance, through acquisition of collaborative evidence, that the identity of another claimant is as declared. Many entity authentication protocols providing various levels of security and usability. Authentication protocols can be further seperated into two categories:

Non-interactive: this is a protocol whereby the claimant is asked by the verifier a fixed (implicit) question to prove its identity. For example: the UNIX password authentication system.

Challenge-Response: this is an interactive protocol where the verifier asks a series of random questions of which the claimant must answer all correctly to prove it's identity. For example: Zero-Knowledge Proof Systems. The security challenge-response protocols can be unconditionally secure (the highest level of security) as the knowledge required could be substantial but such an approach requires extremly secure two-way communication. Furthermore, the system authenticating the person must have the necessary knowledge to pose the proper questions and verify the response. Non-interactive protocol, on the other hand, are much easier to attach making them typically less secure, however, they are much more usable making them the de facto standard for entity authentication.

State of the Art Non-Interactive Authentication Protocols and Attacks

Non-interactive authentication protocols are based on secure hash functions. In the normal scenario, a secure hash function, h, maps an input x to an output, h(x), with the following properties:

compression the bit length, or size, of x is finite and arbitrary, while the size of h(x) is fixed.

computation given h and z it is computationally easy to find h(x).

preimage resistance it is computationally infeasible to find any hashes to the output. Namely, given h, and h(x),it is infeasible to find any preimage x such that x = h(x).

2nd-preimage resistance it is computationally infeasible to find any second input that has the same output as any specified input. Namely, given h, x, and h(x), it is computation infeasible (at a practical level) to find any x' such that x' = h(x).

Examples of secure hash functions are Message Digest 5 (MD5) and Secure Hash Algorithm (SHA-1).

The simplest authentication protocol that uses hash functions is the UNIX password protocol. This protocol is used in a variety of operating systems including Windows operating systems. The idea is that the claimant, holds a public username, C, and a private password, p. The verifier holds a hash ofp, h(p) associated with C. To verify, an unverified claimant provides (C,p) and the server first computes h(p'), and then compares h(p)' with the stored h(p) associated with C. If h(p) = h(p)' , then the claimant is verified. Otherwise, the claimant is rejected.

This authentication protocol is useful since the verifier does not store the private password, ?. It only stores h(p) where it is infeasible to find ? from h(p), by the preimage resistance property of secure hash functions. However many insecurities exist in this protocol. The most devastating attack on unix passwords is the replay attack whereby an eavesdropper, somehow gains (C,p), and can "replay" the authentication protocol.

To protect against replay attacks, Lamport created the Secure Hash Function One- Time Passwords protocol, whereby a password cannot be used twice. The scenario is as follows: the claimant and verifier decide on a fixed value t and iterator i_v and i_c. To start the verifier and claimant set i_v = z^' _c = 0. Next the claimant sends

h^t(p) = h(-h (p)) y-^) , t-times

to the verifier. The verifier now holds (C, i_v, h'(p)) while the claimant holds (C, i_c,p)- To verify, the claimant sends (i_c, ?^hc( ?)). The verifier verifies

= h*(p) and checks that i_c > i_v. If both are true the verifier accepts and sets i_v = i_c + l. Otherwise the verifier rejects and leaves it unchanged.

When i = t - 2, the claimant and verifier must reinitialize, or refresh, by the claimant first authenticates him/herself with the verifier and establishing a private channel. Once the private channel is created the claimant creates a new/?' and sends h'(p') to the verifier. Finally, both the claimant and verifier implicitly reset i_c = i_v = 0.

Lamport's protocol protects against replay attacks and the verifier never stores/?. However, even this approach is susceptible to forced delay attacks. A forced delay attack is when an eavesdropper intercepts C and (i, z^t"!( ?)) before it gets to the verifier and blocks the transmission. Then after sometime, the eavesdropper may impersonate C with a verification using C and (i, h^('l(p)).

If one allows for the claimant and verifier to share a secret,/?, then the protocol can be simplified so that the claimant sends (C,n, h(n\p)), where | is concatenation and n is a nonce. (A nonce is a value used no more than once for the same purpose, like an incrementor or a random number). However, if the server one verifier is attacked and compromised, then the attacker can impersonate the claimant on every other server.

Ideally, to prevent forced delay attacks one can combine the use of random numbers with short response times or timestamps plus appropriate additional techniques. The unique protocol of the present invention does just that and as a result provides protection against both replay and forced delay attacks.

A New Non-Interactive Authentication Protocol

The authentication protocol used by the present invention preferably uses biometric information, random numbers, a clock with bounded drift and an iterator while storing no biometric information with the verifier. In this case the claimant is the Biotoken 100 and the verifier is the CAS server 205.

Variables

C the public userid of the claimant.

c_c, c_v resettable public clocks stored by the claimant and verifier respectively. The claimant's clock is has a drift d for every one million ticks. In the preferred embodiment, the system clock would be incremented every second. The clocks, c_c, c_v, are set to increments every 32 = 2⁵ seconds and is modulo 2ⁿ = 64 = 2⁶ units. Namely in code, if c is a system clock incrementing every second, we check and c_c = cC then we every 32 seconds of c is c » 5 and modulo 64 means just the first 6 bits. Therefore c_c =cC with respect to a unresettable clock c incrementing by seconds is,

cC = ((c»5) & 0x3 f);

If c cannot be reset to 0 then to reset cC, we take an instance of c, namely c = instance at the time of reset and cC will be

cC = (((c-instance)»5) & 0x3f);

i_c, i_v public counters stored by the claimant and verifier respectively. r_c a secret 128-bit random number stored by the claimant.

r a 32-bit nonce (random number or incrementor) stored by both the claimant and verifier.

b secret biometric information, i.e. the template stored on the biotoken.

h a public secure hash function.

t a public threshold before refreshing, i this case t = 2¹⁰ =1024

Variable with primes, such as r'_care considered to be of the same type, in this case r_c, but it is unknown if they are equal, i.e. if r '_c = r_c.

Using this encryption scheme, the biotoken could be initialized by performing the following steps:

1. The claimant creates random numbers, r and r_c. i the perferred embodiment, this is accomplished when the user places a random finger on the scanner resulting in the acquisition of raw fingerprint data and compressing the data. The compressed data bits, without header information, can be considered random for the purposes of this step. This must be repeated until 2 x 128 random data bits is acquired. Other ways of acquiring a random number could also be used.

2. The claimant prepares z'(δ|r_c).

3. The claimant and verifier create an authenticated and private channel to communicate securely without the use of the biotoken.

4. The claimant sends ht(blrc) and r to the verifier.

5. The verifier and claimant implicitly reset cc = cv = ~c = 'iv = 0.

In this implementation, the claimant already has secret information on the biotoken, namely the fingerprint template, b. If the biotoken is somehow physically compromised then one could impersonate the verifier. For this reason, physical security measures could be provided to prevent physical intrusion, such as sealing the enclosure around the token or other measures. Furthermore, additional "secret information" could be stored on the biotoken. For example, upon initialization the claimant could store every intermediate value he/she computes when computing the hash function. Thus the claimant may store h^l(b\r_c),h²(b\r_c), . . ., ^t p r_c on the device as a nice time/space trade off to speed up verification and preserve battery life. Because typing in a full hash decreases usability, it may be preferable to store and transport "folded" hashes. See A Note on Hash Sizes for more information on XOR folding.

Verification

The claimant (in this case, the Bioktoken) is assumed to have (C, i_c, c_c, r', r'_c, b¹), and it is unknown if the claimant truly is C. The verification procedure is as follows:

1. The claimant hashes / ^{" c}(b'|7-'_c).

2. The claimant sends (C,i_c,c_c,h^t~ιc y_c) Θ λ(cdr'))-

3. The claimant increments i_c.

4. Upon reception, the verifier checks the following conditions. If all are correct, the claimant is verified.

(a) The verifier compares the time c_v with c_c if it is within acceptable drift the verifier continues, otherwise it rejects. See A Comment on Time Drift, for more information.

(b) The verifier checks that i_v ≤ i_c.

(c) The verifier calculates ^c(/ ^"'^c(b|r_c)) = ϊ^t(b]r_c) and h(c_c\r), and checks if the following is equal:

This is true when r - r', b = b' and r_c — r'_c with certainty, and otherwise, it is true with probability 1/2* , where 1 is the length of the hash.

If one or more of the above fails, the verifier rejects. 5. Once verified that verifier sets i_v = i_c + 1.

Refresh

In the preferred embodiment, refresh occurs before i_c - 1 - 1 or i_v = t - 1. The refresh process is identical to the reinitialization but the authentication in step 3 is done via the verification procedure just described.

Benefits of the New Protocol

hi this section we briefly discuss the benefits of this protocol for use with the biotoken. We claim that the above protocol protects against replay attacks and forced delay attacks within an arbitrary timeframe. No biometric information is stored on the server. In general, this protocol protects against a compromised verifier from compromising the claimant and other verifiers, also it protects against a variety malicious attacks by the claimant. Finally, due to the one-timeness of the protocol eavesdropping strategies are reduced to breaking the hash function or a forced delay attack within the timeframe.

However, for this protocol to be considered secure, we must first perform an internal audit, next find knowledgeable researchers verify the integrity of the protocol and finally publish the protocol publicly so that the security is in the mathematics rather than the secrecy of the protocol.

Time Drift

In order to implement this process probably, it is important to configure the clocks and time drift to provide the smallest acceptable timeframe with a give drift d and clock modulus 2".

In the preferred embodiment, the server will receive the n-bit clock value c_c from the claimant and must confirm it is within an acceptable timeframe. To do so, the verifier compares the value c_c with the lower bound, bj = ev(l-d/l 000000) (mod 2") and the upper bound bj = c_v(l +d/l 000000) (mod 2"). If b_} ≤ b₂ then the following must hold: If > bz then the following must hold: h ≤ cy < 2" ~ 1, or

0 < c < ba.

If fcks above coa itloa is true the« he verifier accepts, otherwise it rejects.

Fox n = 6 {2^{6 β} 04, used previously), and d s- S3 as per the microlynx document one would check as follows: lot accept * 0; /* 0 » false, otherwise true #/ bl * ⁽(c-iastaac^β) - (iB.t) «{c-ii-s ai-,«eϊ*S3)l/1000000.0}}X64; b2 = ((c-ias aacβ) + <in' >(«c-'iastaac«)*63> iO00O00,O))X64; accept » ( C (M <= ) «se CcC >» M> fcfc (cC <» b2) ) i I

( (bl > b2) ** { ( cC >« bl ) 1 1 ( cC <- b2) ) ) ) ; where c ~ instance = cy.

The reliability of the timeframe check is dependent on the clock drift and can be viewed in two ways. First, how long are the values of c_c valid for? At most a clock value c_c is valid for

2 x ■• XΆ*X etack ticks. 1000000

For example, if a clock tick is every 2⁵ = 32 seconds, d - 53, c_v = 86400 (32 days) then the valid timeframe would be about 9 clock ticks (less than 5 minutes). Note this is a worst case scenario, one would expect a realistic answer to be about 2.5 minutes since the probability a given c_c in this example is valid after 2.5 minutes is less than one half. It goes without saying that a smaller d value could be used to make these bounds better.

Secondly, how well can an adversary guess a valid clock value C_A .> This is both dependent on d and n. Let d(bj, b₂) be the distance between bj and b₂ be defined as:

Once the distance between bi and b₂ is greater than ^'1 , then an adversary has a "good chance" (probability > 2) of guessing a valid c_A.

i general, the probability an adversary can guess a valid C_A is

For this reason, to make these bounds better, a smaller d value could be used, or as is used in the preferred embodiment, a larger n value, since increasing n will decrease the likelihood of guessing exponentially. A Note on Hash Sizes

In one embodiment, the verification procedure involves sending a 2³⁶ bit value. This value is preferred solely for usability purposes. The clock value, c_c, takes 6 bits, the counter, i_c takes 10 bits and that leaves 20 bits for the hash value. Again, these are not fixed by ay means but instead represent one approach to this problem while maintaining usability, hi such a case, a "random" guess would be at least a "one-in-a- million" chance of being correct. Since hashes are typically 128 or 160 bits long, however, the number of bits could be modified substantially to reflect high security (or lower security) applications.

In order to use "typical" hash values in the present invention, an "XOR fold" could be used to preserve the hard core predicate in the hash. To do so we redefine the hash as

where h is the original hash function and/: (0, l}^m - {0,1}²⁰ defined as mapping x ~ x₀,xi, . . . , x_m-ι bits to y =y₀,yι, . . . , yjg bits by

m m for i = 0, . . ., 19. For [ — ] x 20 + i > m, then [ — ] _x2o₊ι⁼ 0. As an example SHA-1

2U 20 produces a 160-bit hash. The following code folds a 160-bit value x to a 20-bit value y assuming an integer is 32 bits, aat gβtSi Unc ±, iat xCS] ) < Wt im ( x[(i/32)] } & ( Oxl « (4X32) >?1:0;

> void xαrQnβToBit(iafc i, iat *ΎS! } i

*val "* Oxi « 4 ; > iat f ( iat x[S] ) i Iflt i,y; for Ci*0; i<i$ø i++) < if ( gβ Sit( i , x ) 5 -corαa«Tø8it(i5K.O,fty⁾ j

> return y; >

2 be more terse, iat f{ iat x[δ] > { in i,y; for <i=0; i<160; 1++) < i c x[ ι 32)3 & (oxi « t ) y ^** Oxl « 4X20;

raεura y;

>

To change this for MD5, one need only loop to 128 and the input would be x [4]. hi the preferred embodiment of this step, both ti^'^fb) and (hc_c\r) are folded independently and are then XOR'ed together.

Referring now to Figure 11, an alternative method for initializing a biotoken is shown. The first step 1100 of the method involves creating and storing a biometric image, hi the preferred embodiment, this is performed with a fingerprint scanner (such as those provided by Authentec) on the biotoken. This provides the link between the person (or living being) with the token. A template is defined 1105 from the image by applying the finger two or more times and the consistent ridges and valleys in the fingerprint are extracted 1110. These template values are then hashed 1115, by using an algorithm such as MD5, and the hashed value of the template is stored in ROM 1120. The hashed value of the consistent template elements are also encrypted. This encryption process is also performed 11130 on a secret value that is stored on the token (and preferably unique to the biotoken). These numbers are then combined 1135 to form a single 128-bit result. This number is then either displayed 1140 or is otherwise transmitted over a network connection to the CAS server 205. The image or template is then used to compare with data that is captured at a later time. The value received by the CAS server 205 is decrypted 1145 and the unique value assigned to the biotoken is extracted from the decrypted value and compared 1150 with the shared secret on the CAS server 205. The remaining portions of the number (representing a hash value of the consistent template elements) are then extracted 1155 and stored 1160 under the user in the event that later verification (or reverification) is required.

Referring now to Figure 12, a flowchart for using a biotoken using an alternative method is shown. The first step of the method involves capturing a biometric image or template 1205, 1210. The image or template is then used to compare with data that is stored on the biotoken. Again, the consistent template elements are extracted 1215 and compared to stored values. In the default case, the comparison is between the hash 1220 of the captured value and the stored 1225 hash value. Alternatively, the captured has value could be hashed and used without comparing to the stored value. In either event, the captured (or stored) finger has value is combined with a counter value 1230 (that is incremented on each use) and the pre-shared secret 1235 and collectively the numbers are once again hashed 1240. If manual entry is expected, some portion of that value is extracted 1245(the process for defining which portions are used must be defined) and is either displayed 1250 or otherwise transmitted 1250. The same process is performed during validation on the CAS server 305. The stored hash value 1255, a counter 1260, and the shared secret 1265 are combined and hashed 1270 and a portion of those values are extracted 1275 are compared 1280 to the transmitted values. This process is repeated after incrementing the counter until a threshold is reached. If there is no match, then authentication (or process of the request) is denied 1285. If a match is successful 1290, then the authentication request (or other process request) is validated and is sent for processing, i the case of a certificate request, a key fetch protocol is invoked 1295 which creates a secure channel with the user could be used to transmit a private code, a PKI certificate, a private key, or other sensitive information that can be used by the person requesting validation to perform other tasks. This might include transmission of encrypted messages on a public computer, digitally signing documents, or any number of other activities that require authentication of the user prior to processing. A slowchart illustrating the DCTP is provided in Figures 13 and 14. While the description above included references to this combined system, each component may also be used individually and it is the expectation of the applicants that such components will be used in a number of difference environments in this manner. As such, the scope of the claims should not be interpreted to require such related but distinct components. Additionally, while this invention will often make use to biometric identification, any other form of identification could be used. For example, a chip or other electronics could be embedded under a human's skin and used to provide a unique identifier for such person, hi the case of animals, this could include a tag or other form of ID on the ear. As such, biometric data should not be construed as a limitation of the claims. Finally, while the authentication step of the method and authentication server of the system have often been described with reference to a computer or networked system, any system that includes or has access to the authentication server (even if just running on a local device or machine) could be adapted to receive and confirm the transmitted password, challenge phrase or ID. For these reasons, the claims should not be limited by these embodiments but should instead be interpreted in accordance with the following claims.

Claims

I CLA :

1) A mobile biometric device comprising: a biometric capture device for capturing one or more pieces of biometric information; a processor; read only memory for storing a shared secret;

RAM for temporarily storing captured biometric information during verification; and a means for transmitting a code, wherein such code does not include any biometric information captured by the biometric capture device.

2) The device of claim 1, wherein the means for transmitting a code is an LCD display.

3) The device of claim 1, wherein the means for transmitting a code is a wireless transmitter.

4) The device of claim 1, wherein the biometric capture device is a fingerprint scanner.

5) A server for authenticating a biometric device comprising a CAS Engine; and a CAS LDAP Proxy.

6) The server of claim 5, wherein the CAS Engine includes biotoken functionality for verifying a biotoken.

7) The server of claim 5, wherein the CAS Engine includes biotoken functionality for initializing a biotoken.

8) The server of claim 6, wherein the server includes memory for storing a secret value that is shared with the biotoken.

9) The server of claim 8, wherein the stored secret value is used to initialize a biotoken.

10) The server of claim 9, wherein the secret value is used to verify a biotoken.

11) The server of claim 5, wherein the server further includes encrypted biometric data.

12) The server of claim 11, wherein the encrypted biometric data is encrypted using a hash function. 13) The server of claim 12, wherein the store biometric data cannot be used to determine the actual biometric data.