WO2007036763A1 - Systeme d'authentification biometrique - Google Patents

Systeme d'authentification biometrique Download PDF

Info

Publication number
WO2007036763A1
WO2007036763A1 PCT/IB2005/004075 IB2005004075W WO2007036763A1 WO 2007036763 A1 WO2007036763 A1 WO 2007036763A1 IB 2005004075 W IB2005004075 W IB 2005004075W WO 2007036763 A1 WO2007036763 A1 WO 2007036763A1
Authority
WO
WIPO (PCT)
Prior art keywords
biotoken
server
biometric
cas
user
Prior art date
Application number
PCT/IB2005/004075
Other languages
English (en)
Inventor
Clovis Najm
Robert Eryou
Damien Norris
Original Assignee
Clovis Najm
Robert Eryou
Damien Norris
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Clovis Najm, Robert Eryou, Damien Norris filed Critical Clovis Najm
Priority to PCT/IB2005/004075 priority Critical patent/WO2007036763A1/fr
Publication of WO2007036763A1 publication Critical patent/WO2007036763A1/fr

Links

Classifications

    • 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
    • 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/3271—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 challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/068—Authentication using credential vaults, e.g. password manager applications or one time password [OTP] applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • 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/56—Financial cryptography, e.g. electronic payment or e-cash
    • 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

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 securely authenticating the identity over any unsecured information network including a verbal conversation.
  • 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.
  • 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 sorts 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 Another approach to the security problem has been provided by biometric authentication systems.
  • 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 invention should provide a simple but secure method of authentication that will work with any present or future network or form of communication. This would include secure and insecure computer networks (such as intranets and internets) but also non-digital forms of communication such as a verbal telephone or radio conversation, or a hand-written document or letter.
  • 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 for printing a one-time password, and/or a transmitting device for transmitting the code wirelesslyto a computer.
  • 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 identifier contains random information from a random number generator to ensure that each user's identifying information is unique each time they are initialized with the system.
  • 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, Zigbee, 80211(b)/(g) wireless, and others) without use of a certificate.
  • distance transmission methods such as RF, Bluetooth, Zigbee, 80211(b)/(g) wireless, and others
  • 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).
  • the password or ID could be displayed or transmitted (or both) as configured.
  • 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.
  • 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.
  • FIG. 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 GINA
  • 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.
  • 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, Zigbee, 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.
  • 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.
  • 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 with a one-touch login.
  • 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 fingerprint. This information is collected during initialization and is used to compute 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 IPlanet 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 305 and CAS-LDAP-Proxy 310.
  • CAS-Engine 305 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.
  • 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.
  • 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.
  • 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
  • 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
  • the repository layer 435 will allow the changing of underlying repository (like RDBMS/File/LDAP) configutation will preferably use standard Java APIs like JDB C/ 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-LD AP- 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.
  • 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 CASEngineHandlerlmpl 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. For example, if the communication between CAS-ENGINE 305 and CAS-LDAP-Proxy 310 is direct Java call, there will be CASEngineLookupImpl (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.
  • 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 305and 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.
  • 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 read/write 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:
  • WlxLoggedOutSASO 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-LD AP-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 GDMA modules.
  • WlxWkstaLockedSAS() 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-LD AP-proxy.
  • the control On successful authentication the control is passed to the 3rd party GINA component thus supporting forward chaining. In 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: DisplayCustomisedLogonBoxO - 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: GetCurrentGINAO - This function could check for any previous GINA entry in the registry and retrieve its path to perform the forward chaining.
  • BioTokenAuthenticationO - This function could be called from within DisplayCustomisedLogonBox. The main purpose of this function would be to make a connection with the CAS-LD AP-proxy 310 and pass the network username and the BioCode. It gets a success or a failure response from the CAS-LD AP-proxy 310 depending on the authenticity of the user. This function is a part of CAS-SDK 230.
  • SetAutoAdmin() 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.
  • SetAutoCredentialsO - 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.
  • GetPrevNamePasswordO - 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.
  • PutPrevNamePasswordO - This function could be called from WlxLoggedOutSAS function. After successful logging in of the user and before exiting from
  • WlxLoggedOutSAS the PutPrevNamePassword is called.
  • the username 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
  • DecryptPasswordO - This function could be called from GetPrevNamePassword function. This function is preferably used to decrypt the encrypted password.
  • ReadConfigurationO This function could be called from the main program and reads anything that has to be read from the configuration.
  • GenerateKeyO - 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.
  • This module will accept the user initialization string and write to directory for future BioToken verification process by making use of CAS-SDK.
  • 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 fa ⁇ ade 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 410 could 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, MAP 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 fa ⁇ ade 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
  • 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.
  • 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-LD AP-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 C AS-LD AP- Proxy 1005, 1010, 1015, 1020, 1025 and CAS-Engine 1030 is based on RMI.
  • several CAS-LD AP-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 system may also be implemented in a lightweight fashion as a minimal Server API .
  • a TCP/IP daemon for UNIX preferably the OpenBSD seucre operating system.
  • the functionality would be limited to basic authentication only, with storage of persistant user information offloaded to a relational database such as Oracle or Microsoft SQL Server.
  • the benefits of this approach are its simplicity, which in turn leads to greater scalability and ease of certification with federal information processing and security standards. This will allow deployment in sensitive networks such as in the military and financial verticals.
  • the combination of the biotoken and either the CAS system or Pl Server API 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 methods for initialization and operation of the biotoken.
  • the local workstation that would be used by the client in conjunction with such a server would preferably include the following wireless amenities, which allow the user to peform a "one touch" login without thaving to type in the biocode or their user credentials
  • BioCode Transceiver A wireless-enabled device capable of receiving biocodes from the Mobio wirelessly and making them available to the computer. Software on the computer would then receive the credentials and biocode and automatically enter them into login fields on the computer. The Biocode Transceiver could also provide functionality for wireless enrollment by users.
  • the biotoken would interact wirelessly with a Wireless Door Reader.
  • This unit is essentially identical to the Biocode Transceiver but able to oputput in a Weigand format compatible with door access systems.
  • the door reader can authenticate to the door controller hardware either by emulating a standard prox- card or using the Pl Server Algorithm if supported by the door access hardware and software.
  • 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 separated 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. 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.
  • 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-I 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 of p, h(p) associated with C.
  • This authentication protocol is useful since the verifier does not store the private password, p. 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 p. However, even this approach is susceptible to forced delay attacks.
  • a forced delay attack is when an eavesdropper intercepts C and (i,h' ⁇ '(p)) 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' ⁇ '(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);
  • biotoken could be initialized by performing the following steps:
  • the claimant creates random numbers, r and r c . In 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 prepares
  • 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 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 , f), and it is unknown if the claimant truly is C.
  • the verification procedure is as follows:
  • the claimant sends (C,i c ,c c ,h' ⁇ ic (b' ⁇ r' c ) ®
  • the verifier 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.
  • the verifier rejects.
  • 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 cv x d . . . '
  • 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.
  • 20 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,
  • both h' ⁇ tc (b) 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. In 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 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 flowchart illustrating the DCTP is provided in Figures 13 and 14 and is further described below.
  • the BioToken operates in 2 distinct modes: initialization and standard operation.
  • the initialization phase is performed on a blank or 'virgin' token only once. This phase binds the users' unique biometric data into the physical token which further generates the one of the seed values required for the CPU to calculate the token codes.
  • the initialization phase includes the following steps: capture users biometric image, create template for biometric info, cryptographically hash the template with unique token fixed key (pre-shared secret), erase fixed key, set internal RAM increment counter to zero, store the hashed template in RAM, encrypt the template hash value, LCD display and/or transmit the encrypted template value for transmission to authentication server.
  • the authentication server receives the encrypted hashed template, decrypts the hashed templates with fixed key (pre-shared secret), erases fixed key (pre-shared secret), sets increment counter to zero, stores and links hash template value to user profile in encrypted storage.
  • Standard operation mode occurs after the initialization phase in two styles: Event- Synchronous or Challenge-Response.
  • This phase consists of the following steps: capture users biometric image, create template for biometric info, cryptographically hash the template, increment the RAM counter by one, cryptographically hash the increment counter with the template hash, LCD display and/or transmit hashed template value for transmission to authentication server.
  • the authentication server receives the token code, hashes the stored template with the stored increment value, compares the received code with the calculated code; if match — access granted else increment stored counter by one, recalculate (hashes the stored template with the stored increment value), and recompile results - repeat n times where n is based on future token code thresholds (16 as an example). Implementations: Communication Channel:
  • Biotoken output code is hashed into a human readable, short string of numeric or alpha-numeric digits displayed on an LCD. The user then inputs the displayed code into another system capable of digit entry (computer, keypad, mobile device).
  • Biotoken code is transmitted in full to the encrypting authentication server for validation.
  • a human readable biotoken code can be generated communication over analog, offline channels for later verification, (i.e. a signed credit card slip)
  • Client to Server Symmetric Encryption system (omits the requirement for key exchange Asymmetric system like RSA and DH that are 10,000 time slower than Symmetric key systems - doesn't work on low end devices) using a perpetual pre- shared secret list. Both client and server can generate the values
  • RSA and DH are widely used in SSL to produce the initial SYMMETRIC encryption key exchange - referred to as enveloping.
  • the major draw back for mobile device is the lack of processing power and the requirement for a key exchange.
  • ASYMMETRIC encryption is 10,000 more processor intensive (and power hungry) then SYMMETRIC encryption making implementation on mobile processors difficult.
  • the client and serer have a perpetual pre-shared secret list removing the requirement for any key exchange protocol. After successful authentication, the two sides can immediately enter into a VPN uses lightweight encryption protocols. The pre-shared Biotoken is never used again therefore acting a one-time session key.
  • the processing center uses the encrypting authentication server, as defined above, to verify is the Biotoken code is valid. The transaction is acceptable or rejected based on this comparison. Because BioToken codes are onetime, non-repeating, stolen or repeated credit card numbers or transactions are impossible. Using the CID Code or a credit card number format for the Biotoken code eases adoption as the current deployment of system that accept a credit card number or CID format are fixed. Further, a small form factor card with an on-the-fly writeable magnetic strip. The key to adoption is the ability to interoperate with existing systems such as credit card readers, card terminals and even "card not present" systems like phone and online systems.
  • the communication channel (step 5) is housed in a separate hardware unit which accepts communication from the Biotoken. (i.e. a Docking Station for the token that is connected to the communication channel).
  • a separate hardware unit which accepts communication from the Biotoken. (i.e. a Docking Station for the token that is connected to the communication channel).
  • Biometric Capture Stage The user places their biometric data on the sensor for imaging, (reference FPC patent).
  • Biometric Image is reduced to a template, (reference FPC patent).
  • Biometric template is cryptographically hashed using a one-way hashing function (reference MD5, SHA).
  • Biometric Template is stored to local BioToken random access memory (RAM).
  • Biometric templates are imaged, templated, hashed and stored (steps 1-5) Depending on Biometric type, the number of stored Templates may vary (1-2 for retinal, 1-10 for finger etc.).
  • Unique Serial is read from read only memory (ROM).
  • ROM read only memory
  • the unique serial is placed on protective ROM at time of BioToken manufacturer. This is also know as the BioToken pre-shared secret and takes the form of a varying bit length string which is cryptographically produced based on randomly collected data at time of manufacture ensuring each BioToken was a random pre-shared secret.
  • the HASH result from (step 4) becomes the plain text and the pre- shared secret from (step 7) becomes the encryption key as inputs for a symmetric key encryption algorithm, (reference some symmetric encryption algorithms which produce the same length cipher text as the input plain text length; Rijndael, DES are good, El Gamal is not good)
  • the resultant from (step 8) is a consistent bit string length.
  • the resultant from (step 9) is distilled into a human readable format (i.e. Base 10, Base 16) (i.e. 32 alpha-numeric digits). If the unit uses a direct means for a communication channel (i.e. Analog voice, WiFi, Bluetooth, RE, Ethernet, CDMA, TDMA, etc), the resultant from (step 9) is directly transmitted to the Encrypting Authentication Server via the communication channel.
  • a communication channel i.e. Analog voice, WiFi, Bluetooth, RE, Ethernet, CDMA, TDMA, etc
  • step 11 The output of the distillation and concatenation process (step 10) is then displayed on the user visual display system.
  • the BioToken user then reads the resultant code from (step 10) and manually inputs it into an intermediary device (i.e. a keypad, keyboard, mobile device etc.).
  • This intermediary device is connected to the Encrypting Authentication Server using a direct communication channel (i.e. Analog voice, WiFi, Bluetooth, RF, Ethernet, CDMA, TDMA, etc.)
  • the user also transmits a username, identification number and/or password combination with the resultant from (step 10) to be used by the authentication server to retrieve the BioToken user profile.
  • the Encrypting Authentication Server receives the resultant from (step 10).
  • the Unique Serial / pre-shared secret is read from the user profile. This value is identical to the value in (step 7).
  • the transmitted resultant from (step 13) becomes the cipher text and the pre-shared secret from (step 14) becomes the decryption key as inputs for a symmetric key decryption algorithm which reverses the function in (step 8).
  • the resultant from this function produces the identical value in (step 4).
  • step 15 The resultant from (step 15) is then stored to a user profile.
  • Biometric Capture Stage The user places their biometric data on the sensor for imaging, (reference FPC patent).
  • Biometric Image is reduced to a template, (reference FPC patent).
  • step 2 Verification of template biometric from (step 2) is compared with stored template biometric from RAM.
  • step 3 If the result of the template comparison in (step 3) is positive (a match), then the stored biometric template is retrieved from RAM.
  • step 3 If the result of the template comparison in (step 3) is negative (not a match), then the flow ends with an access lockout for specified amount of time.
  • Biometric template from (step 4) is cryptographically hashed using a one-way hashing function (reference MD5, SHA).
  • Increment Counter is read from RAM. Once the Increment counter is read, it is incremented by the value of adding one whole number. The increment counter is the number of events or uses that the BioToken successfully been used. The first time a BioToken is used in normal operation the Increment Counter is zero. In some implementations the Increment Counter is padded with leading zeros.
  • Unique Serial is read from read only memory (ROM).
  • ROM read only memory
  • the unique serial is placed on protective ROM at time of BioToken manufacturer. This is also know as the BioToken pre-shared secret and takes the form of a varying bit length string which is cryptographically produced based on randomly collected data at time of manufacture ensuring each BioToken was a random pre-shared secret.
  • step 6 combined with the pre-shared secret from (step 8) combined with the increment counter from (step 7) are hashed using a one-way hashing algorithm to produce a fixed length bit string.
  • the resultant from (step 8) is a consistent bit string length.
  • the resultant from (step 9) is distilled into a human readable format (i.e. Base 10, Base 16) then truncated from the original length to a shorter length (i.e. 8 alpha-numeric digits). If the unit uses a direct means for a communication channel (i.e. Analog voice, Analog voice, WiFi, Bluetooth, RE, Ethernet, CDMA, TDMA, etc), the resultant from (step 9) is directly transmitted to the Encrypting Authentication Server via the communication channel.
  • a communication channel i.e. Analog voice, Analog voice, WiFi, Bluetooth, RE, Ethernet, CDMA, TDMA, etc
  • step 10 The output of the distillation and concatenation process (step 10) is then displayed on the user visual display system.
  • the BioToken user then reads the resultant code from (step 10) and manually inputs it into an intermediary device (i.e. a keypad, keyboard, mobile device etc.).
  • This intermediary device is connected to the Encrypting Authentication Server using a direct communication channel (i.e. WiFi, Bluetooth, RE, Ethernet, CDMA, TDMA, etc.).
  • the user also transmits a username, identification number and/or password combination with the resultant from (step 10) to be used by the authentication server to retrieve the BioToken user profile.
  • the Encrypting Authentication Server receives the resultant from (step 10).
  • the stored user representation is read from the user profile. This value is identical to the value in (step 6).
  • Increment Counter is read from the user profile.
  • the increment counter is the number of events or uses that the BioToken successfully been used. In some implementations the Increment Counter is padded with leading zeros.
  • the Unique Serial / pre-shared secret is read from the user profile. This value is identical to the value in (step 8).
  • the value from (step 15) combined with the pre-shared secret from (step 17) combined with the increment counter from (step 16) are hashed using a one-way hashing algorithm to produce a fixed length bit string.
  • step 18 The resultant from (step 18) is compared with the value obtained in (step 14).
  • reference PRNG retrieves a number corresponding to a stored user representation.
  • the corresponding stored user representation is retrieved according to the number from (step 2).
  • the number from (step 2) is then sent back to the to the user via the communication channel.
  • biometric Capture Stage The user places their biometric data on the sensor for imaging, (reference FPC patent).
  • Biometric Image is reduced to a template, (reference FPC patent).
  • Verification of template biometric from (step 2) is compared with stored template biometric from RAM.
  • step 8 If the result of the template comparison in (step 8) is positive (a match), then the stored biometric template is retrieved from RAM.
  • step 8 If the result of the template comparison in (step 8) is negative (not a match), then the flow ends with an access lockout for specified amount of time.
  • Biometric template from (step 9) is cryptographically hashed using a one-way hashing function (reference MD5, SHA).
  • Increment Counter is read from RAM. Once the Increment counter is read, it is incremented by the value of adding one whole number. The increment counter is the number of events or uses that the BioToken successfully been used. The first time a BioToken is used in normal operation the Increment Counter is zero. In some implementations the Increment Counter is padded with leading zeros.
  • Unique Serial is read from read only memory (ROM).
  • ROM read only memory
  • the unique serial is placed on protective ROM at time of BioToken manufacturer. This is also know as the BioToken pre-shared secret and takes the form of a varying bit length string which is cryptographically produced based on randomly collected data at time of manufacture ensuring each BioToken was a random pre-shared secret.
  • the resultant from (step 13) is a consistent bit string length.
  • the resultant from (step 14) is distilled into a human readable format (i.e. Base 10, Base 16) then truncated from the original length to a shorter length (i.e. 8 alpha-numeric digits). If the unit uses a direct means for a communication channel (i.e. WiFi, Bluetooth, RE, Ethernet, CDMA, TDMA, etc), the resultant from (step 14) is directly transmitted to the Encrypting Authentication Server via the communication channel.
  • a communication channel i.e. WiFi, Bluetooth, RE, Ethernet, CDMA, TDMA, etc
  • step 15 The output of the distillation and concatenation process (step 15) is then displayed on the user visual display system.
  • the BioToken user then reads the resultant code from (step 15) and manually inputs it into an intermediary device (i.e. a keypad, keyboard, mobile device etc.).
  • This intermediary device is connected to the Encrypting Authentication Server using a direct communication channel (i.e. WiFi, Bluetooth, RE, Ethernet, CDMA, TDMA, etc.).
  • the user also transmits a username, identification number and/or password combination with the resultant from (step 15) to be used by the authentication server to retrieve the BioToken user profile.
  • the Encrypting Authentication Server receives the resultant from (step 15).
  • the stored user representation is read from the user profile. This value is identical to the value in (step 11).
  • Increment Counter is read from the user profile.
  • the increment counter is the number of events or uses that the BioToken successfully been used. In some implementations the Increment Counter is padded with leading zeros.
  • the Unique Serial / pre-shared secret is read from the user profile. This value is identical to the value in (step 13).
  • the value from (step 20) combined with the pre-shared secret from (step 22) combined with the increment counter from (step 21) are hashed using a one-way hashing algorithm to produce a fixed length bit string.
  • step 24 The resultant from (step 23) is compared with the value obtained in (step 19).
  • Biometric Capture Stage The user places their biometric data on the sensor for imaging, (reference FPC patent).
  • Biometric Image is reduced to a template, (reference FPC patent).
  • step 2 Verification of template biometric from (step 2) is compared with stored template biometric from RAM.
  • step 3 If the result of the template comparison in (step 3) is positive (a match), then the stored biometric template is retrieved from RAM.
  • step 3 If the result of the template comparison in (step 3) is negative (not a match), then the flow ends with an access lockout for specified amount of time.
  • Biometric template from (step 4) is cryptographically hashed using a one-way hashing function (reference MD5, SHA).
  • Increment Counter is read from RAM. Once the Increment counter is read, it is incremented by the value of adding one whole number. The increment counter is the number of events or uses that the BioToken successfully been used. The first time a BioToken is used in normal operation the Increment Counter is zero. In some implementations the Increment Counter is padded with leading zeros.
  • Unique Serial is read from read only memory (ROM).
  • ROM read only memory
  • the unique serial is placed on protective ROM at time of BioToken manufacturer. This is also know as the BioToken pre-shared secret and takes the form of a varying bit length string which is cryptographically produced based on randomly collected data at time of manufacture ensuring each BioToken was a random pre-shared secret.
  • step 6 combined with the pre-shared secret from (step 8) combined with the increment counter from (step 7) are hashed using a one-way hashing algorithm to produce a fixed length bit string.
  • the resultant from (step 8) is a consistent bit string length.
  • the resultant from (step 9) is distilled into a human readable format (i.e. Base 10, Base 16) then truncated from the original length to a shorter length (i.e. 8 alpha-numeric digits). If the unit uses a direct means for a communication channel (i.e. WiFi, Bluetooth, RE, Ethernet, CDMA, TDMA, etc), the resultant from (step 9) is directly transmitted to the Encrypting Authentication Server via the communication channel.
  • a communication channel i.e. WiFi, Bluetooth, RE, Ethernet, CDMA, TDMA, etc
  • step 10 The output of the distillation and concatenation process (step 10) is then displayed on the user visual display system.
  • the BioToken user then reads the resultant code from (step 10) and manually inputs it into an intermediary device (i.e. a keypad, keyboard, mobile device etc.).
  • This intermediary device is connected to the Encrypting Authentication Server using a direct communication channel (i.e. WiFi, Bluetooth, RE, Ethernet, CDMA, TDMA, etc.).
  • the user also transmits a username, identification number and/or password combination with the resultant from (step 10) to be used by the authentication server to retrieve the BioToken user profile.
  • the Encrypting Authentication Server receives the resultant from (step 10).
  • the stored user representation is read from the user profile. This value is identical to the value in (step 6).
  • Increment Counter is read from the user profile.
  • the increment counter is the number of events or uses that the BioToken successfully been used. In some implementations the Increment Counter is padded with leading zeros.
  • the Unique Serial / pre-shared secret is read from the user profile. This value is identical to the value in (step 8).
  • the value from (step 15) combined with the pre-shared secret from (step 17) combined with the increment counter from (step 16) are hashed using a one-way hashing algorithm to produce a fixed length bit string.
  • step 18 The resultant from (step 18) is compared with the value obtained in (step 14).
  • Biometric Capture Stage The user places their biometric data on the sensor for imaging, (reference FPC patent).
  • Biometric Image is reduced to a template, (reference FPC patent).
  • step 2 Verification of template biometric from (step 2) is compared with stored template biometric from RAM.
  • step 3 If the result of the template comparison in (step 3) is positive (a match), the flow continues to (step 6).
  • step 3 If the result of the template comparison in (step 3) is negative (not a match), then the flow ends with an access lockout for specified amount of time.
  • BioToken i.e. a green light etc.
  • Increment Counter is read from RAM. Once the Increment counter is read, it is incremented by the value of adding one whole number. The increment counter is the number of events or uses that the BioToken successfully been used. The first time a BioToken is used in normal operation the Increment Counter is zero. In some implementations the Increment Counter is padded with leading zeros.
  • Unique Serial is read from read only memory (ROM).
  • ROM read only memory
  • the unique serial is placed on protective ROM at time of BioToken manufacturer. This is also know as the BioToken pre-shared secret and takes the form of a varying bit length string which is cryptographically produced based on randomly collected data at time of manufacture ensuring each BioToken was a random pre-shared secret.
  • the pre-shared secret from (step 8) combined with the increment counter from (step 7) are hashed using a one-way hashing algorithm to produce a fixed length bit string.
  • the resultant from (step 8) is a consistent bit string length.
  • the resultant from (step 12) is displayed to the user then reads the resultant code and manually inputs it into an intermediary device. If the unit uses a direct means for a communication channel the resultant from (step 12) is directly transmitted to the Authentication Server via the communication channel. Additional elements may be passed in this step such as credit card number, transaction value, expiry date or other fixed codes.
  • the proceeding value is then pass through a LUHN/Mod 10 (ANSI X4.3) generator to proceed the suffix Base 10 digits to produce a valid credit card number corresponding to the LUHN/Mod 10 (ANSI X4.3) method of verification.
  • the resultant from (step 14) is displayed to the user then reads the resultant code and manually inputs it into an intermediary device. . If the unit uses a direct means for a communication channel the resultant from (step 14) is directly transmitted to the Authentication Server via the communication channel. Additional elements may be passed in this step such as transaction value, expiry date or other fixed codes.
  • the Authentication Server receives the resultant from (step 13) or (step 15).
  • the user key i.e. the whole credit card number or credit card number part
  • the user key is extracted from the value obtained in (step 16).
  • Increment Counter is read from the user profile.
  • the increment counter is the number of events or uses that the BioToken successfully been used. In some implementations the Increment Counter is padded with leading zeros.
  • the Unique Serial / pre-shared secret is read from the user profile. This value is identical to the value in (step 8).
  • the pre-shared secret from (step 20) combined with the increment counter from (step 19) are hashed using a one-way hashing algorithm to produce a fixed length bit string.
  • the preceding value is then passed through a LUHN/Mod 10 (ANSI X4.3) generator to proceed the suffix Base 10 digits to produce a valid credit card number corresponding to the LUHN/Mod 10 (ANSI X4.3) method of verification.
  • Resultant from (step 21) is truncated to the required Base 10 string length (i.e. 3 or 4 digits)
  • step 25 The resultant from (step 23) or (step 24) is compared with the value obtained in (step 16).
  • step 26 If the Comparison from (step 25) matches, proceed to (step 27). If the Increment Threshold has not been exceeded, loop through (steps 19- 25) until either a positive match in (step 25) or the Increment Threshold has been exceeded then proceed to (step 28).
  • Encrypting Authentication Server receives BioToken output from (Step 2) via communication channel.
  • Increment Counter value is retrieved from the user profile.
  • Pre-Shared Secret is retrieved from the user profile.
  • the value from (step 4) combined with the pre-shared secret from (step 6) combined with the increment counter from (step 5) are hashed using a one-way hashing algorithm to produce a fixed length bit string.
  • step 7) The resultant from (step 7) is compared with the value obtained in (step 3). If the values match, Access is Granted (step 13). If the values do not match, processing continues to (step 9)
  • step 8) The comparison from (step 8) is negative; processing loops through (step 4, 5, 6, 7, 8) for the number set as the 1st Threshold until either the comparison in (step 8) is positive and the processing is terminated by (step 13) or the loop count exceeds the 1st Threshold value where the 2nd Threshold flag is set.
  • step 10 The comparison from (step 10) is negative; processing loops through (step 4, 5, 6, 7, 10) for the number set as the 2nd Threshold value until either the comparison in (step 10) is positive and the processing continues to (step 12) or the loop count exceeds the 2nd Threshold value where the 2 Threshold flag is set and processing is terminated in (step 11)
  • Processing is terminated with an Access Denied after 1st and 2nd Threshold values were exceeded without a positive match in (step 8) or (step 10).
  • the 2nd Threshold increment count from (step 7) is recorded.
  • a request for a second BioToken value from the BioToken user is sent.
  • the User submits another BioToken value repeating (step 1 - 3).
  • the positive increment count, increment by one, from (step 7) is used to calculate the value from (step 7). If the 2 user submitted BioToken code from (step 3) and the current value from (step 12) match, the processing is terminated by (step 13). If the values do not match, the processing is terminated by (step 11).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Biodiversity & Conservation Biology (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)

Abstract

La présente invention a trait à un dispositif et un serveur biométrique mobile permettant la validation d'une personne qui a initialisé le jeton biométrique et a communiqué un ou des codes générés par le jeton biométrique vers le serveur sur une voie de communications sécurisée ou non sécurisée. Le dispositif biométrique, ou jeton biométrique, comporte un moyen pour la capture d'une donnée biométrique, pour le hachage d'une certaine portion de la donnée biométrique, et pour la transmission ou l'affichage d'un code qui est calculé à l'aide d'une valeur d'horloge, un nombre aléatoire, une fonction de hachage sécurisée et un compteur. Le serveur comprend des fonctions nécessaires à l'initialisation du dispositif biométrique, au stockage de valeurs clés en réponse à l'initialisation, et à la validation de codes qui sont prévus en réponse à l'utilisation future du dispositif biométrique suite à une requête pour validation. L'invention a également trait à des fonctions et des caractéristiques additionnelles pour la création d'un espace sécurisé, apte à une vérification et d'utilisation privée sur le dispositif ou la machine, tel qu'un ordinateur ou un téléphone cellulaire, suite à la validation.
PCT/IB2005/004075 2005-09-29 2005-09-29 Systeme d'authentification biometrique WO2007036763A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/IB2005/004075 WO2007036763A1 (fr) 2005-09-29 2005-09-29 Systeme d'authentification biometrique

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/IB2005/004075 WO2007036763A1 (fr) 2005-09-29 2005-09-29 Systeme d'authentification biometrique

Publications (1)

Publication Number Publication Date
WO2007036763A1 true WO2007036763A1 (fr) 2007-04-05

Family

ID=37899407

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2005/004075 WO2007036763A1 (fr) 2005-09-29 2005-09-29 Systeme d'authentification biometrique

Country Status (1)

Country Link
WO (1) WO2007036763A1 (fr)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012156648A1 (fr) * 2011-05-18 2012-11-22 Morpho Acces protege par biometrie a des dispositifs electroniques
US8959357B2 (en) 2010-07-15 2015-02-17 International Business Machines Corporation Biometric encryption and key generation
FR3027753A1 (fr) * 2014-10-28 2016-04-29 Morpho Procede d'authentification d'un utilisateur detenant un certificat biometrique
US9558128B2 (en) 2014-10-27 2017-01-31 Seagate Technology Llc Selective management of security data
US9600443B2 (en) 2012-01-30 2017-03-21 International Business Machines Corporation Tracking entities by means of hash values
US9680651B2 (en) 2014-10-27 2017-06-13 Seagate Technology Llc Secure data shredding in an imperfect data storage device
US9698992B2 (en) 2012-10-15 2017-07-04 Obshestvo S Ogranichennoj Otvetstvennostyu “Laboratoriya Elandis” Method for signing electronic documents with an analog-digital signature with additional verification
KR20180069435A (ko) * 2016-12-15 2018-06-25 주식회사 아이리시스 생체 정보를 이용한 otp 인증 방법 및 이를 실행하는 시스템
US10033729B2 (en) 2016-04-14 2018-07-24 International Business Machines Corporation Dynamic phrase base authentication system
US11645653B2 (en) 2015-11-06 2023-05-09 Visa Europe Limited Transaction authorization

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003093923A2 (fr) * 2002-04-30 2003-11-13 Robert Eryou Systeme et appareil permettant d'authentifier un systeme ou un reseau

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003093923A2 (fr) * 2002-04-30 2003-11-13 Robert Eryou Systeme et appareil permettant d'authentifier un systeme ou un reseau

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8959357B2 (en) 2010-07-15 2015-02-17 International Business Machines Corporation Biometric encryption and key generation
FR2975550A1 (fr) * 2011-05-18 2012-11-23 Morpho Acces protege par biometrie a des dispositifs electroniques
WO2012156648A1 (fr) * 2011-05-18 2012-11-22 Morpho Acces protege par biometrie a des dispositifs electroniques
US10042818B2 (en) 2012-01-30 2018-08-07 International Business Machines Corporation Tracking entities by means of hash values
US9600443B2 (en) 2012-01-30 2017-03-21 International Business Machines Corporation Tracking entities by means of hash values
US9698992B2 (en) 2012-10-15 2017-07-04 Obshestvo S Ogranichennoj Otvetstvennostyu “Laboratoriya Elandis” Method for signing electronic documents with an analog-digital signature with additional verification
US9558128B2 (en) 2014-10-27 2017-01-31 Seagate Technology Llc Selective management of security data
US9680651B2 (en) 2014-10-27 2017-06-13 Seagate Technology Llc Secure data shredding in an imperfect data storage device
FR3027753A1 (fr) * 2014-10-28 2016-04-29 Morpho Procede d'authentification d'un utilisateur detenant un certificat biometrique
US9984220B2 (en) 2014-10-28 2018-05-29 Morpho Method of authenticating a user holding a biometric certificate
EP3016315A1 (fr) * 2014-10-28 2016-05-04 Morpho Procédé d'authentification d'un utilisateur détenant un certificat biométrique
US11645653B2 (en) 2015-11-06 2023-05-09 Visa Europe Limited Transaction authorization
US10033729B2 (en) 2016-04-14 2018-07-24 International Business Machines Corporation Dynamic phrase base authentication system
KR20180069435A (ko) * 2016-12-15 2018-06-25 주식회사 아이리시스 생체 정보를 이용한 otp 인증 방법 및 이를 실행하는 시스템
KR101960797B1 (ko) 2016-12-15 2019-07-17 주식회사 아이리시스 생체 정보를 이용한 otp 인증 방법 및 이를 실행하는 시스템

Similar Documents

Publication Publication Date Title
US9774449B2 (en) Systems and methods for distributing and securing data
CA2463286C (fr) Systeme d'authentification multifactorielle
US20160149873A1 (en) Electronic commerce with cryptographic authentication
WO2007036763A1 (fr) Systeme d'authentification biometrique
JP6906521B2 (ja) 生体認証プロトコル標準のシステムおよび方法
JP2005532736A (ja) 生物測定学的私設キーインフラストラクチャ
CN101507233A (zh) 用于提供对于应用程序和基于互联网的服务的可信单点登录访问的方法和设备
Kim et al. On the security of two remote user authentication schemes for telecare medical information systems
AU2003247117B2 (en) System and apparatus for authenticating to a system or network
US20060129815A1 (en) Generation of identities and authentication thereof
Pampori et al. Securely eradicating cellular dependency for e-banking applications
EP2530618B1 (fr) Système d'ouverture de session avec accès distribué
Ajvazi et al. SOAP messaging to provide quality of protection through Kerberos Authentication
AU2014240194B2 (en) Systems and methods for distributing and securing data
Iqbal et al. Integrating Authentication method on Java Based Mobile Devices

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 05857773

Country of ref document: EP

Kind code of ref document: A1