Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
  • G06F21/31—User authentication
  • G06F21/32—User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
  • G06F21/31—User authentication
  • G06F21/42—User authentication using separate channels for security data
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/60—Protecting data
  • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
  • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
  • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
  • H04L63/0861—Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
  • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
  • H04L9/3231—Biological data, e.g. fingerprint, voice or retina
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
  • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/2149—Restricted operating environment
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
  • H04L2209/76—Proxy, i.e. using intermediary entity to perform cryptographic operations
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
  • H04L2209/80—Wireless
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
  • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
  • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords

Definitions

• 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.
• 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.
• 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.
• 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.
• biometric authentication systems such as a system
• biometric data from a person such as a thumb print, a retinal scan, a hand print, face shape, etc.
• 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.
• 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.
• 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.
• the biotoken also includes a display and/or transmitter for transmitting i the first step, the biotoken must be initialized.
• 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.
• biometric information such as a fingerprint scan
• biometric information 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).
• 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.
• the authenticating server could verify the identity of the token by using the corresponding public key.
• "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.
• one embodiment could include a fingerprint scanner, digital certificate, and a number generator or 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.
• a variable password or ID could be adjusted by generating a new number after a certain time interval has passed.
• 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.
• 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.
• 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.
• 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.
• 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
• FIG. 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.
• Figure 14 is a flowchart illustrating another embodiment of the digital certificate transfer protocol.
• 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.
• a system and method 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.
• 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.
• 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.
• 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.
• an RF transmitter 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.
• peripheral technologies such as a USB cradle or wireless transmitter
• the biotoken includes ROM 105, a scanner 110, transmitter 115, processor 120, and secondary memory 125, such as RAM, and an LCD screen 130.
• 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.
• 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.
• DCTP digital certificate transfer process
• the CAS- SDK can be used by 3rd party applications to integrate BioToken Based authentication and support for DCTP protocol.
• the authentication server of the present invention consists of two modules CAS-Engine
• 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
• the CAS-Engine 305 will also preferably include the DCTP functionality.
• 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.
• 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.
• 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.
• WAP wireless access protocol
• 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.
• 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.
• 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.
• 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.
• a block diagram illustrating the CAS-LDAP- Proxy 310 is provided.
• the proxy 310 will have different backend implementations depending on the manner in which data is stored and retrieved.
• 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.
• 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.
• 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.
• CASEngineLookuphiipl (not shown) which implements and inside the implementation of getCASEngineHandler () function and will return an instance of CASEngineHandlerlmpl class 325.
• RMI the implementation CASEngineLookupRMI (not shown) could perform an RMI lookup and get handle to CASEngineHandlerRMI object 330.
• 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.
• 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.
• 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.
• 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.
• WinLogon functions 510 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.
• 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.
• 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.
• 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.
• Helper and Utility Module functions 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.
• 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.
• BioToken initialization 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.
• 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.
• 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 - 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• a round-robin DNS load-balancing can be implemented to distribute requests to the CAS server tier 930.
• a hardware load-balancer provides additional robustness and flexibility in the load-balancing mechanism and is preferred.
• 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.
• all tiers 930, 940, 960 of the architecture can gracefully handle failure of individual applications or server hardware without interruption of service. Server 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.
• 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.
• most of the components can be built using the Java programming language.
• the CAS 205 can be deployed on any operating system supporting the Java platform.
• FIG. 10 An alternate embodiment of the CAS system is illustrated in Figure 10.
• the CAS-LDAP-Proxy 310 and CAS-Engine 305 are separated and are deployed on different physical machines 1005, 1010, 1015, 1020, 1025, 1030.
• the communication channel(s) between CAS-LDAP-Proxy 1005, 1010, 1015, 1020, 1025 and CAS-Engine 1030 is based on RMI.
• 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.
• biotoken and the CAS system described above represent a substantial improvement in the security of such processes.
• 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.
• 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.
• 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.
• the verifier a fixed (implicit) question to prove its identity.
• the verifier a fixed (implicit) question to prove its identity.
• the verifier a fixed (implicit) question to prove its identity.
• 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.
• 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.
• the system authenticating the person must have the necessary knowledge to pose the proper questions and verify the response.
• Non-interactive protocol 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.
• Non-interactive authentication protocols are based on secure hash functions.
• a secure hash function, h maps an input x to an output, h(x), with the following properties:
• bit length, or size, of x is finite and arbitrary, while the size of h(x) is fixed.
• MD5 Message Digest 5
• SHA-1 Secure Hash Algorithm
• 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.
• 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.
• Lamport created the Secure Hash Function One- Time Passwords protocol, whereby a password cannot be used twice.
• 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)).
• the protocol can be simplified so that the claimant sends (C,n, h(n ⁇ p)), where
• a nonce is a value used no more than once for the same purpose, like an incrementor or a random number).
• the server one verifier is attacked and compromised, then the attacker can impersonate the claimant on every other server.
• 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.
• the claimant is the Biotoken 100 and the verifier is the CAS server 205.
• 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.
• the system clock would be incremented every second.
• cC (((c-instance)»5) & 0x3f);
• r c a secret 128-bit random number stored by the claimant.
• biotoken could be initialized by performing the following steps:
• 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.
• the claimant and verifier create an authenticated and private channel to communicate securely without the use of the biotoken.
• the claimant sends ht(blrc) and r to the verifier.
• 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 2 (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.
• the claimant (in this case, the Bioktoken) is assumed to have (C, i c , c c , r', r' c , b 1 ), and it is unknown if the claimant truly is C.
• the verification procedure is as follows:
• the claimant hashes / " c (b'
• the claimant sends (C,i c ,c c ,h t ⁇ c y c ) ⁇ ⁇ (cdr'))-
• the verifier Upon reception, the verifier checks the following conditions. If all are correct, the claimant is verified.
• the refresh process is identical to the reinitialization but the authentication in step 3 is done via the verification procedure just described.
• 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
• the verification procedure involves sending a 2 36 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.
• 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.
• 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;
• both ti ' ⁇ fb) and (hc c ⁇ r) are folded independently and are then XOR'ed together.
• 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.
• 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.
• 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.
• biometric identification any other form of identification could be used.
• 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.
• biometric data should not be construed as a limitation of the claims.

Applications Claiming Priority (5)

Publications (1)

Family

ID=29406780

Family Applications (1)

Country Status (4)

Cited By (1)

Families Citing this family (13)

Family Cites Families (3)

• 2003
  • 2003-04-30 EP EP03747532A patent/EP1506469A2/de not_active Withdrawn
  • 2003-04-30 CA CA2483989A patent/CA2483989C/en not_active Expired - Fee Related
  • 2003-04-30 AU AU2003247117A patent/AU2003247117B2/en not_active Ceased
  • 2003-04-30 WO PCT/IB2003/003301 patent/WO2003093923A2/en not_active Application Discontinuation

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events