Note: Descriptions are shown in the official language in which they were submitted.
CA 02483989 2004-10-26
WO 03/093923 PCT/IB03/03301
System and Apparatus for Authenticating to a System or
Network
Field of the Invention
This invention relates primarily to the field of system authentication and
related identification devices. More specifically, this invention relates to a
system and
method for providing a link between an identity on a network and one or more
pieces
of biometric data associated with that identity and a method for securing
transmitting
such information over an information network.
Background of the Invention
Internetworks of the future will allow and promote universal access. Users
will be able to access the network at a multitude of access points separated
by
significant geographic distance and many administrative boundaries. This
phenomenon has introduced new security issues compared to the traditional
fixed
networks. This is mostly because of the lack of physical protection of the
mobile
network access points and transmission of the information using radio or other
forms
of communication.
In the normal networking environment, security is established when a person
and a system create a shared key, such as a password, that is used to
"identify" the
person as a user on the network and to enable privileges accordingly.
Unfortunately,
many programs (and good guesses) provide unauthorized parties, such as
computer
hackers and the like, the ability to attempt an unlimited number of log-in
attempts
which will eventually crack such a simplistic system. This presents a
significant
security concern.
New technologies have been developed to resolve this difficult but each
presents security holes that create significant difficulties and defeat any
attempts at
"real" security. For example, one company has developed a device that receives
a
new code after a fixed period of time that must be used to log in to a
network. While
this approach does reduce the probability that a hacker will "crack" the code
without
the device, a loss or theft of the device immediately gets around such
protections. In
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.
CA 02483989 2011-01-06
2
Additionally, these sort of devices rely upon the server and device being
synchronized
and in many cases these devices will get out of synch. This means that the
code
entered by the user will not be shared by the system or network and will be
rejected.
Another approach to the security problem has been provided by biometric
authentication systems. In such a system, biometric data from a person, such
as a
thumb print, a retinal scan, a hand print, face shape, etc. is stored in a
database. Later,
when a person wished to be authorized, a scan of some type is performed and
the
stored data and captured data are compared. This solution has many problems
that
include: 1) a scanner of the biometric data must be provided at each entry
point; 2) the
data must be stored on a central database; and 3) the person many not wish to
have
such sensitive data stored across many servers for each authentication system.
A similar problem is evident with credit cards and similar "ID cards" that
provide a link between a piece of plastic and a financial account. In such
instances, a
person that has stolen the card can often use it without restriction by faking
the
person's signature (although rarely confirmed anyway) until the card is
reported as
lost or stolen. Indeed, when purchasing products online, it is often the case
that a
signature is not even required as the data from the card is entered on an
electronic
form without any other corresponding code or ID.
What is needed, then, is an authentication system that does not require
specialized hardware or scanning equipment, that stays synchronized with a
central
server, that does not require centralized storage of each person's biometric
data, and
yet still uses biometric data (rather than simple possession) to authenticate
a person to
their identity.
Summary of the Invention
The present invention provides such a system and method. The system of the
present invention is comprised of two primary components: an authentication
server
and a biometric capture device (hereinafter referred to as a "biotoken"). The
biotoken
is comprised of a biometric capture system (such as a fingerprint scanner, a
retinal
scanner, DNA scan, or similar devices) that stores biometric information and
can later
be used to verify biometric (or other unique) input by comparing the captured
biometric data with the stored biometric data. In the preferred embodiment,
the
biometric capture device is a fingerprint scanner and the biometric
information (or an
encryption of hashed value of such information) is stored in either RAM or ROM
on
the device. Additionally, the biometric information maybe the actual
information or
CA 02483989 2004-10-26
WO 03/093923 PCT/IB03/03301
3
may instead be a template of the biometric information. This might include, by
way
of example, a scan of discreet "data points" on a fingerprint rather than
storing all
points (such as an image or other data file) of the fingerprint. The biotoken
also
includes a display and/or transmitter for transmitting
In the first step, the biotoken must be initialized. As will be further
described
herein in greater detail than required for enablement, the biotoken begins an
initialization process that begins with the capture of one or more pieces of
information
unique to a person, such as biometric information. For example, biometric
information, such as a fingerprint scan, could be captured. This information
need
only be stored on the device. While it could also be stored on a central
server, such
storage is not required and such an approach faces significant drawbacks
(although
such approaches could represent a simplification of the present invention).
In the next step, the biotoken begins a process of exchange whereby the
biotoken downloads, updates, or verifies a unique certificate or identifier
that can be
stored on the biotoken. This certificate or identifier can be used to
communicate a
log-in or other password that can be used to authenticate a person to any
electronic
system (or related peripherals). For example, this could download a private
certificate, such as those offered by Verisign, Certicom, and other companies,
that
could be used to "sign" any "passwords" being communicated. In such a system,
the
authenticating server could verify the identity of the token by using the
corresponding
public key. Alternatively, "manual" entry could be used whereby the password
or
identifier is entered directly into the system or input using distance
transmission
methods (such as RF, bluetooth, wireless, and others) without use of a
certificate.
For example, one embodiment could include a fingerprint scanner, digital
certificate, and a number generator or receiver. In the case of a receiver,
the token
could receive a new password or ID every fixed (or variable) time interval
that could
only be displayed or transmitted responsive to proper biometric
authentication.
Authentication would be achieved by comparing the captured biometric value(s)
with
the stored biometric value(s). Once authentication has occurred, the password
or ID
could be displayed or transmitted (or both) as configured. This could include
a fixed
password or ID, or any other form of variable or adjustable password or ID
wherein
the method and variables used to generate such adjustable passwords or IDs are
shared so that each side can compare the received password or ID with the
password
or ID stored on the server. Again, in the simplest case, a variable password
or ID
CA 02483989 2004-10-26
WO 03/093923 PCT/IB03/03301
4
could be adjusted by generating a new number after a certain time interval has
passed.
As long as the server and biotoken have a means for sharing such a fixed
number (a
process which is well-known and understood), the authentication step could be
easily
implemented.
This is but one embodiment. The preferred embodiment of the invention is a
far more secure approach that provides even more substantial improvements over
any
prior art. It includes two additional components. First, an encryption
methodology is
provided that enables an extraordinarily secure manner of generating a
password or
code dynamically that would prevent a hacker from making a guess about the
next
password or ID even if they knew of every password or ID that had come before
it.
This approach represents a fundamental improvement in a manner in which data
is
encrypted prior to being communicated to another system and specifically
provides a
block to two common security attacks (as further described below). An
extension of
this security improves the server such that the server itself is not subject
to being
corrupted in a way that would enable a rogue server to fake "authenticating" a
token
that should not be authenticated.
Second, a methodology for transferring the information over a network such
the password or ID is not intercepted or otherwise manipulated in a way that
allows a
third party to use the captured data to enable them to use the password or ID
for
malicious purposes. This is crucial in an environment where the step of
authentication travels over unprotected public networks or where the server
itself
transmits sensitive data back to the token, such as a private certificate. The
protocol of
the preferred embodiment is called DCTP-digital certificate transfer protocol.
This
protocol can be used to transmit a private digital certificate (or any
sensitive data or
key) to a machine or system such that, once a person has been properly
authenticated,
can be used to sign documents, receive applications, execute transactions, or
perform
other actions as may be enabled by the system on to which the private
certificate (or
data) has been transmitted.
Each of these pieces, both together and independently, represent important
new systems for managing personal identities, providing authentication, and
creating
an audit trail such that fraud and other forms of malicious or irregular
activities cannot
be perpetrated on the secure system. The systems can be used to protected
data, to
protect financial accounts, to protect national secrets, to protect physical
facilities
(such as airports), to protect computer networks, to enable access to public
goods, and
CA 02483989 2004-10-26
WO 03/093923 PCT/IB03/03301
even to slow efforts by terrorist (and other targets of homeland security) and
other
illegal elements that might otherwise have free run and access to important
resources.
It is for this reason that the applicants urge expedient review and approval
of these
inventions for patenting.
Brief Description of the Figures
Figure 1 is a block diagram of one embodiment of the biotoken;
Figure 2 is a high level architecture of one embodiment of the authentication
server;
Figure 3 is a block diagram of the CAS LDAP Proxy;
Figure 4 is a block diagram of the CAS engine;
Figure 5 is a block diagram of the CAS 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.
Detailed Description of the Preferred Embodiment(s)
The following description provides a description of several distinct
inventions.
In the preferred system, each of these components is used and applied to
provide a
distinctly secure process for identifying, authenticating, enabling, and
auditing one or
more individuals on or to a system. While much of this description will
include
references to this combined system, each component may also be used
individually
and it is the expectation of the applicants that such components will be used
in a
number of difference environments in this manner. As such, the scope of the
claims
CA 02483989 2004-10-26
WO 03/093923 PCT/IB03/03301
6__
should not be interpreted to require such related but distinct components.
Additionally, while this invention will often make use to biometric
identification, any
other form of identification could be used. For example, a chip or other
electronics
could be embedded under a human's skin and used to provide a unique identifier
for
such person. In the case of animals, this could include a tag or other form of
ID on the
ear, for example.
Certain terms will be used throughout this description. They include:
CAS The Authentication Server
DCTP Digital Certificate Transfer
Protocol
SDK Software Development Kit
GINA Graphical Interface for Network
Authentication
JNDI Java Naming and Directory
Interface
LDAP Light-weight directory access
protocol
DLL Dynamic Link Library
In the simplest embodiment of the present invention, a system and method is
provided for authenticating an individual to a network through a network
device. This
is achieved by having a hidden rotating password, or ever changing challenge
phrase,
that is only displayed when biometric information scanned by a device or token
is
identical to one or more stored biometric profiles that were created upon
initialization.
Upon authentication of the biometric identity, a number or challenge phrase
appears.
The number or challenge phrase is then entered into a network access device or
other
system by manual entry, such as a keypad, or through another communications
interface, such as radio frequency, bluetooth, or other forms of wireless
communications. Once the challenge phrase, ID or password has been entered
into the
network access device, it is communicated to the server. This can be
accomplished via
several means such as an encrypted channel over a public network, a dedicated
network connection or, if less secure means are acceptable, over any public
computer
network. Responsive to authentication by the server, the authenticating device
(either
the token itself or the network access device) is then transferred their
online identity,
CA 02483989 2004-10-26
WO 03/093923 PCT/IB03/03301
7
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.
In contrast with the prior art, where biometric security systems are
constrained
to a single system with a connected reader or scanner, the present invention
provides a
portable biometric scanner that can be adapted for any system. For example,
many
people use key cards to open secured areas, such as offices or research labs.
Clearly,
another person could easily take and use the card to get into the facility. By
adding an
extra field that can be received and transmitted by the key card reader,
however, the
present invention could be adapted to include an RF transmitter and could
transmit the
number for use with the existing door panels (or at least added as an
additional
peripheral) thereby permitting the same device to be used for a computer
network as a
perimeter security device. This means that either approach could be used
without
needed to completely replace the prior system. This is particularly try in
setting where
significant investments may have already been made but the existing security
is no
longer as secure as it needs to be, such as at airports.
A similar benefit is accomplished when using the system on a computer
network. Rather than having a password, a registered user could either enter
the
number manually into the log-in screen or could use peripheral technologies,
such as a
USB cradle or wireless transmitter, to transmit the number and authenticate
the user.
Perhaps the most important benefit of this approach, however, is the fact that
a
user's privacy is maintained. One of the reasons that there has been great
resistance
to biometric devices is the sense that your very tissue and DNA is being
taken.
Assuming that becomes the main ID, identity theft could take on horrific
proportions
with private companies and other commercial entities storing and manipulating
such
information. In contrast, the present system stores the biometric information
in only
one place and that information is never shared with another person (or a
server). In
other words, in contrast to most solutions, the present system provides
security
without infringing the privacy of its users.
Referring now to Figure 1, a block diagram of a biometric device or biotoken
is shown. In this embodiment, the biotoken includes ROM 105, a scanner 110,
transmitter 115, processor 120, and secondary memory 125, such as RAM, and an
LCD screen 130. In the illustrated embodiment, the ROM 105 is used to store a
shared secret, a fingerprint template, or both. The scanner 110 is used to
scan a
CA 02483989 2004-10-26
WO 03/093923 PCT/IB03/03301
8
fingerprint and create a "template" or image of the captured fingerprint. This
information is collected during initialization and is used to compate during
the
verification process (each as further described below). The transmitter 115 is
used to
transmit the "biocode" or password that will be used to authenticate the
person to a
system running (or otherwise connected to) the CAS server. The processor 120
is
used to generate the code based on an initialization and verification process
and may
also be used to apply secondary authentication means, such as a PKI
certificate.
Referring now to Figure 2, a high-level block diagram of the Authentication
Server is shown. Each of these components is described in further detail below
In the
illustrated embodiment, the CAS Server 205 includes both a CAS-Engine 305 (see
Fig. 3) and LDAP proxy 310 (see Fig. 3) that are hosted on one physical
machine,
such as a computer server. The User profile & Key store 210 could be unique or
could be a 3rd party LDAP server (such as Microsoft Active Directory or
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. The
CAS-
SDK can be used by 3rd party applications to integrate BioToken Based
authentication and support for DCTP protocol.
Authentication Server (CAS)
Referring now to Figure 3, in the preferred embodiment of the present
invention, the
authentication server of the present invention consists of two modules CAS-
Engine
305 and CAS-LDAP-Proxy 310.
CAS-Engine 305
The CAS-Engine 305 is preferably implemented using a "global" language that is
supported on multiple platforms, such as java, and includes the BioToken
Verification
Process. The CAS-Engine 305 will also preferably include the DCTP
functionality.
CA 02483989 2004-10-26
WO 03/093923 PCT/IB03/03301
9
When in operation, the CAS-Engine 305 can use a database, scuh asn an LDAP
Server, for storing the user profile along with BioToken information, groups,
rules/policies and key-split files. Alternatively, the Key-Split files may be
stored in a
separate common LDAP server. In the preferred embodiment, the LDAP server will
be accessed using standard vendor independent APIs like JNDI. In the java-
based
implementation, the protocol of communication between LDAP Proxy 310 and CAS-
Engine 305 will be a direct java call. CAS-Engine 305 can also be configured
to
support the searching of remote LDAP servers for user's public-keys.
Referring now to Figure 4, a block diagram of a sample embodiment of the CAS-
Engine 305 is provided. As illustrated, the CAS-Engine 305 can be further
broken
down into following sub-modules
CAS-Engine Handler 405 - This handler 405 is a protocol mapper component,
which converts the requests from external components to CAS-Engine method
calls.
The external component in this case is CAS-LDAP-Proxy. The communication
between the external component and CAS-Engine could be direct j ava call or
RMI or
could be anything. CAS-Engine is preferably made protocol independent in such
a
way that, if another protocol other than the LDAP/S protocol, such as HTTP/S
or
wireless access protocol (WAP) needs to be supported, only the CAS-LDAP-Proxy
need be replaced with appropriate protocol proxy server.
Admin Functionality 410- This sub module 410 will preferably handle all the
admin
functionality that CAS needs to support.
BioToken Functionality 415- This sub module 415 will preferably handle
BioToken
verification, initialization and resynchronization functionality. This
functionality is
further explained below with reference to Figure X.
DCTP Functionality 420- This sub module 420 will preferably handle the DCTP
functionality. This functionality is further explained below with reference to
Figure
X.
Crypto Toolkit Facade 425 - This sub module is used to decouple the above 3
modules from the underlying Crypto toolkit used. This sub module would
preferably
allow the replacement underlying toolkit, if required, without affecting the
core
engine implementation.
Helper Classes 430 - These are set of Java Helper classes for Logging,
debugging,
configuration and some conversions functions required for normal operation of
the
CAS-Engine 310.
CA 02483989 2004-10-26
WO 03/093923 PCT/IB03/03301
Repository Layer 435 - The repository layer 435 will allow the changing of
underlying repository (like RDBMS/File/LDAP) configutation will preferably use
standard Java APIs like JDBC/JNDI. This module 435 will also handle connection
pooling, interfacing with multiple repository, etc. This layer 435 will also
preferably
handle the extensibility requirements of supporting different types of
repository from
different vendors.
CAS-LDAP-Proxy 310
The CAS-LDAP-Proxy 310 is preferably an LDAP/S protocol compliant
proxy that is a front-end listener and communicates with clients that
communicate
using LDAP protocols. For example, this proxy would be responsible for
accepting
requests from the CAS Server 205. The CAS-LDAP Proxy 305 and CAS-Engine 310
are preferably running on a single physical machine. This proxy 310 does not
need to
implement relaying of requests to 3rd party LDAP Servers will preferably only
service requests that are meant for CAS-Engine 310.
In operation, CAS LDAP Proxy 310 listens to the client requests on a
particular port (or ports) that has been configured. For example, this port
could be
provided in an XML file. The proxy 310 will listen to the requests on two
separate
ports, one port for the requests in normal mode (i.e. standard LDAP requests)
and the
other port is for the requests in SSL [LDAPS requests] mode. The CAS-LDAP-
Proxy
310 would also preferably be configured to communicate with CAS-ENGINE 305
over different communication channels ( such as Direct Java Call and RMI).
This
configuration information may also be read from the XML based configuration
file.
Referring again to Figure 3, a block diagram illustrating the CAS-LDAP-
Proxy 310 is provided. As is well-understood in the art, the proxy 310 will
have
different backend implementations depending on the manner in which data is
stored
and retrieved. For example, BackendJDBC could interface with RDBMS over JDBC
for storage/retrieval of data. In the ullustrated embodiment, a backend,
called
BackendCAS 312, does the interfacing with CAS-ENGINE 305.
The BackendCAS 312 will get handle to CASEngineHandler interface 320.
The CASEngineHandler 320 will have different implementations depending upon
communication channel between BackendCAS 312 and the CAS-Engine 305. For
example, the implementation could include a CASEngineHandlerlmpl 325 for
direct
java call and CASEngineHandlerRMl 330 for RMI communication.
CA 02483989 2004-10-26
WO 03/093923 PCT/IB03/03301
11
The BackendCAS 312 will get the handle to CASEngineHandler interface 320
from a class that uses the CASEngineLookup interface 314. In the preferred
embodiment, different implementations of CASEngineLookup interface 314 can be
registered with BackendCAS 312 depending on the communication mechanism
between CAS-ENGINE 305and CAS-LDAP-Proxy 310. For example, if the
communication between CAS-ENGINE 305 and CAS-LDAP-Proxy 310 is direct java
call, there will be CASEngineLookuplmpl (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
CASEngineLookupRMl (not shown) could perform an RMI lookup and get handle to
CASEngineHandlerRMl object 330.
With the above architecture, the CAS-LDAP-Proxy 305 and CAS-ENGINE
310 are decoupled in such a way that communication channel between them can be
changed to anything by having different implementations of CASEngineHandler
Interface 320 and changing the getCASEngineHandler 0 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. In the
preferred
embodiment, this component 220 is a Windows GINA module that is used for
Windows desktop users to authenticate using BioToken based authentication.
This
module 220 could be developed as a pass-thru GINA stub.
In operation, this module 220 will accept the BioToken code from the user and
will open a secure communication channel 260 with CAS server 205 during
verification. In the illustrated example, the CAS-GINA 220 is using MAPS for
creating a secure channel 260. A windows logon dialog box can be provided and
customized to accept Windows userid, Windows domain password as well as the
BioToken code. The Network (Windows, Netware, etc.) username and domain
password will also preferably be passed to MSGINA or another 3rd party (i.e.
GINA
chaining) GINA to complete the Network (Windows, Netware, etc.)
authentication.
Referring not to Figure 5, a block diagram of one embodiment of the CAS-
GINA module 220 is shown. In the preferred embodiment, the CAS-GINA module
220 will consist of 3 sub modules: Winlogon functions 510, helper and utility
functions 520 and the GUI module 530. The WinLogon function 510 preferably
CA 02483989 2004-10-26
WO 03/093923 PCT/IB03/03301
12
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.
Some of the WinLogon functions 510 that could be implemented are describee
below:
WlxLoggedOutSAS() - This function coul be invoked by the winlogon process
whenever it detects a SAS and no user is logged in. A customized logon screen
is
displayed to the user instead of the standard windows logon screen. This
screen
prompts the user to enter his network username, network password, and BioCode
and
domain name if the machine is on a domain. The network username and the
BioCode
are passed to the CAS-LDAP-proxy and the user is authenticated by BioToken
methods. On successful authentication the network username and the network
password is passed to the default MSGINA or to any 3rd party GINA component
for
windows network authentication thus supporting forwarding chaining of GINA
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-LDAP-proxy. 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.
Some of the GUI Module functions 530 that could be provided include:
DisplayCustomisedLogonBox() - This function could be called from
WlxLoggedOutSAS and WlxWkstaLockedSAS. This function displays the
customized windows logon box. The customized logon box prompts the user to
enter
his network username, network password, and BioCode and domain name if the
machine is on a domain. The user is also given an option to locally logon to
his
machine in case of any network problems. In case of user choosing the local
logon
CA 02483989 2004-10-26
WO 03/093923 PCT/IB03/03301
13
option BioCode authentication is not done for him. The network username and
the
network password are passed to MSGINA for windows network authentication.
Some of the Helper and Utility Module functions that could be provided
include:
GetCurrentGlNA() - This function could check for any previous GINA entry in
the
registry and retrieve its path to perform the forward chaining.
BioTokenAuthentication() - 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.
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.
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 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.
EncryptPassword() - 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.
CA 02483989 2004-10-26
WO 03/093923 PCT/IB03/03301
14
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 fuunction. This function preferably gets the username or
userid from
the calling function and generates a symmetric key based on the userid or
username.
The symmetric key is returned to the calling function.
CAS-Enrollment
This is a Web based application developed in JSP/Servlet to do the Self-
Service of user's and CryptoLex BioToken initialization. This module will
accept the
user initialization string and write to directory for future BioToken
verification
process by making use of CAS-SDK.
The functionality required in this Web Interface for BioToken initialization
is
simple, it just needs to validate the user against the 3rd party LDAP using
standard
userid-password based authentication first, then take the users BioToken
initialization
string(4 x 8 chars) and send it to CAS Server for storing them into the
repository for
future BioToken/BioCode verification. The self-service functionality will
support
user registration, forgot password and change-password features.
The CAS-SDK interface can be segregated into Admin, BioToken and DCTP
related APIs. The CAS-SDK implementation will make use of Crypto Toolkit
facade
to decouple the implementation from underlying toolkit used. The Communication
layer will handle the protocol specific functionality that is required based
on
underlying protocol used. The Communication layer will be designed and
implemented in such a way that it can made as a pluggable module, allowing
usage of
different implementation of communications layer to support different
protocol.
CAS-Admin
Referring now to Figure 6, a block diagram of one embodiment of the CAS
admin module 410 is shown. In the preferred embodiment, the CAS admin module
410 is a web based application developed in JSP/Servlet. It would ideally
handle the
CAS user management, group management, Crypto-proxy/Crypto-browser rule
management and activity reporting. The user, group and rule management
functions
would preferably include create, delete, search, association and update. The
CAS-
Admin 410could also have an interface for managing the Policies/Rules of
Crypto-
CA 02483989 2004-10-26
WO 03/093923 PCT/IB03/03301
proxy/Crypto-browser centrally and assigning these Policies/Rules to the users
or
groups.
The CAS-ADMIN and CAS-ENROLLMENT modules 410 illustrated are
preferably developed in HTML/JSP and may also be purely based on Java to
insure
platform independence. The primary blocks of the CAS admin module 410 are
further described below.
Presentation Layer 605- This layer 605 contains the HTML/JSPs and javascript
functions. The responsibility of this layer 605 is to display the end-user GUI
interface,
accept and validate user inputs and then submit the data in the form of HTML
forms
to controller layer.
Controller Layer 610 - The controller layer 610 responsibility is to extract
the data
submitted, convert it into format wrapper classes 615 accept and call
appropriate
wrapper class functions 620. In the preferred embodiment, there would be
separate
controller JSP for each functionality, such user management, group management,
management reporting, and related functions.
Wrapper Classes 615 and Utility Functions 620 - In the preferred embodiment,
the
wrapper classes 615 are the pure Java classes that handle the communication to
and
from CAS-SDK layer 230. These classes 615 are used by both presentation layer
605
and controller layer 610 JSPs. The utility functions 610 would include more
basic
utilities such as data conversion, data extraction and logging functions.
CAS- SDK 230
Referring now to Figure 7, a sample embodiment of the CAS SDK 230 is shown.
This SDK 230 is used to integrate the 3rd party applications to support
BioToken
based authentication. This SDK 230 will preferably be developed in C++ and
Java so
that it is supported on many hardware platforms. The functionalities of this
SDK 230
are Biotoken verification 710, administration and enrollment 720 and support
DCTP
protocol 730. The other modules like CAS-GINA 220, Crypto-proxy 225, Crypto-
browser 225, CAS-ENROLLMENT/CAS-ADMIN 215 will make use of CAS-SDK
230 for all their communication with CAS-ENGINE 305.
Crypto-Proxy Module & Crypto-browser
Referring now to Figure 8, a sample crypto-proxy 225 is shown. The crypto-
proxy 225 is the proxy that will be installed on a client desktop. The Crypto-
proxy
225 will be "application-protocol aware". In other words, based on the
application
protocol and Policies/Rules defined, it will do the necessary operations (such
as
CA 02483989 2004-10-26
WO 03/093923 PCT/IB03/03301
16
digitallly signing documents, network authentication, encryption, etc) to the
application protocol headers and/or payload. In the preferred embodiment, the
crypto-proxy meets the OpenPGP specification via the OpenPGP Handler 820. The
Protocols that Crypto-proxy can support include HTTP 802, IMAP 808, POP3 806
and SMTP 804. With this flexibile system design, additional protocols can be
supported with minimum effort. The Crypto-proxy will also support the
forwarding
of BioCode along with password to the protocol-server for authentication. The
Crypto-proxy 225 will ideally be compatible with most of the standard web-
browsers
and email clients.
The CAS SDK 230 will be used by the crypto-proxy 225 for authentication
and downloading the key. The crypto proxy 225 will preferably use LDAP/S
protocol
while communicating with CAS Server 205 for authentication, retrieving
Policies/Rules and downloading of key.
The Crypto-Browser 225 is preferably designed to act as a browser Java applet
that employs the same functionality as the Crypto-Proxy 225 on HTTP/HTML
GET/POST actions. This would provide a secure browsing interface.
As further illustrated in Figure 8, the Crypto-proxy module 225 will consists
of following sub modules:
BioToken Input Handler 810 - This module 810 will take care of the capturing
of the
user's userid and BioCode. In the preferred implementation, a Java based GUI
can be
used to capture this information. However, other methods of capturing the
BioCode
can be integrated by reimplementing this module alone.
Configuration Handler 815- This module 815 will preferably take care of
capturing
and reading all the configuration entries required by the Crypto-proxy module
225.
BioToken Verifier 825- This sub module 825 will handle the verification of
BioToken either through CAS-SDK 230 or pass-through to remote server.
DCTP Handler 830- This sub module 830 will preferably handle the DCTP
functionality by making use of CAS-SDK 230.
Rule Handler 840- This sub module 840 will preferably parse the XML file
downloaded from CAS server 205 and will determine the decision on the
operation
that needs to be done for a particular protocol and user.
Private-Key Store 850- This sub module 850 will preferably take care of
reading/storing the private key in memory securely.
CA 02483989 2004-10-26
WO 03/093923 PCT/IB03/03301
17
OpenPGP Handler 820 - This sub module 820 will preferably do all the necessary
operations for supporting PGP-like functionality such as signing, encrypting,
generating headers, in each case according to OpenPGP specification. This
module
will make use of Crypto toolkit facade 860 to do the above operations.
Protocol Handler 870- This sub module 870, along with the OpenPGP handler
module 820, will take care of adding new protocols that can support in the
secure
proxy seamlessly.
In the preferred embodiment, the present system is implemented in a manner
that is scalable, fail safe and efficient. A sample system embodiment of the
CAS
system is illustrated in Figure 9. The benefits of illustrated deployment of
the CAS
server and preferred characteristics of such a system will be described below.
Load Balancing
The CAS system architecture can be implemented in a highly scalable and
robust by providing load-balancing mechanisms 910,920 at all tiers of the
architecture, preferably using a combination of hardware- and software load-
balancing.
CAS Server
Load-balancing 910 at the CAS server tier 930 is preferably implemented
using a hardware load-balancer that distributes incoming LDAP requests to a
cluster
of identical CAS servers 205. Alternatively, a round-robin DNS load-balancing
can be
implemented to distribute requests to the CAS server tier 930. However, a
hardware
load-balancer provides additional robustness and flexibility in the load-
balancing
mechanism and is preferred.
LDAP
Load-balancing 920 and scalability at the database tier 940 is preferably
implemented using clustering mechanism. Having multi-master replication in a
server cluster 950 provides a high level of scalability at the LDAP directory
server tier
960.
Redundancy
The illustrated architecture of the CAS provides a high level of redundancy at
all tiers 930, 940, 960 eliminating single-point-of-failure and thus ensures a
high
availability in mission-critical implementations. In such an implementation,
all tiers
CA 02483989 2004-10-26
WO 03/093923 PCT/IB03/03301
18
930, 940, 960 of the architecture can gracefully handle failure of individual
applications or server hardware without interruption of service.
Server Failure
If CAS server 205 fails due to hardware or software failure, the hardware load-
balancer 910 will notice the failure when trying to dispatch incoming CAS
requests to
the CAS server 205. The load balancer 910 will mark the server 205 as
unavailable
and will redirect the request to other CAS servers. Since each CAS Engine 305
running on a server 205 has access to same data, any CAS server 205 available
can
handle requests. Thus, users will not be affected by CAS server 205 failure.
LDAP Failure
In the preferred embodiment, the LDAP directory servers 950 would also
provide hot-failover mechanisms and Multiple-Master replication as well as
Master-
Slave replication to guarantee uninterrupted service in case of a hardware or
software
failure.
Multi-master replication allows a subtree of LDAP entries to be mastered by
more
than one Directory Server; that is, each master server can accept updates for
entries
within a replicated subtree. Each master can replicate add, delete, modify,
and rename
operations to the other master and to multiple slave servers. The replication
process
used between one master and another is the same as that used between a master
and a
slave. If one master is unreachable for some period of time (due to hardware
failure,
software failure, or network failure), the other master continues to accept
updates and
can replicate the changes to the read-only replicas. A load balancing hardware
920, or
a Directory Access Router can be placed in front of the master servers 950 to
facilitate
smooth fail-over.
Platform Independency
The CAS system architecture can be implemented for maximum platform
neutrality by using platform-independent language and supporting industry
standard
protocols for seamless interoperability. The following provide variations or
components that may be used to maximize interoperability.
Operating System
In the preferred embodiment, most of the components can be built using the
Java programming language. In such a case, the CAS 205 can be deployed on any
operating system supporting the Java platform.
CA 02483989 2004-10-26
WO 03/093923 PCT/IB03/03301
19
LDAP Server
The CAS 205can use standard LDAP v3 for accessing user records and other
information stored in any Directory server conforming to the LDAP standard.
An alternate embodiment of the CAS system is illustrated in Figure 10. In the
illustrated deployment, the CAS-LDAP-Proxy 310 and CAS-Engine 305 are
separated
and are deployed on different physical machines 1005, 1010, 1015, 1020, 1025,
1030.
In this embodiment, the communication channel(s) between CAS-LDAP-Proxy 1005,
1010, 1015, 1020, 1025 and CAS-Engine 1030 is based on RMI. In this scenario,
several CAS-LDAP-Proxies 1005, 1010, 1015, 1020, 1025 clustered together
communicate with a single CAS-Engine 1030 instance on a separate physical
machine. This deployment also has same characteristics as the deployment
described
above with reference to Figure 9, however this approach gives administrator
more
flexibility in terms of deployment.
The combination of the biotoken and the CAS system described above
represent a substantial improvement in the security of such processes. In
order to
provide even greater security, however, the system may also use the following
secure
method for initializing and operation the biotoken. A brief background on some
basic
encryption building blocks is provided.
At the most fundmental level, the entire system is premised on a need for
entity authentication. Entity Authentication is the technique to allow one
party, the
verifier, to gain assurance, through acquisition of collaborative evidence,
that the
identity of another claimant is as declared. Many entity authentication
protocols
providing various levels of security and usability. Authentication protocols
can be
further seperated into two categories:
Non-interactive: this is a protocol whereby the claimant is asked by the
verifier a
fixed (implicit) question to prove its identity. For example: the UNIX
password authentication system.
Challenge-Response: this is an interactive protocol where the verifier asks a
series
of random questions of which the claimant must answer all correctly to prove
it's identity. For example: Zero-Knowledge Proof Systems.
CA 02483989 2004-10-26
WO 03/093923 PCT/IB03/03301
20-
The security challenge-response protocols can be unconditionally secure (the
highest
level of security) as the knowledge required could be substantial but such an
approach
requires extremly secure two-way communication. Furthermore, the system
authenticating the person must have the necessary knowledge to pose the proper
questions and verify the response. Non-interactive protocol, on the other
hand, are
much easier to attach making them typically less secure, however, they are
much
more usable making them the de facto standard for entity authentication.
State of the Art Non-Interactive Authentication Protocols and Attacks
Non-interactive authentication protocols are based on secure hash functions.
In the
normal scenario, a secure hash function, h, maps an input x to an output,
h(x), with the
following properties:
compression the bit length, or size, of x is finite and arbitrary, while the
size of h(x) is
fixed.
computation given h and z it is computationally easy to find h(x).
preimage resistance it is computationally infeasible to find any hashes to the
output.
Namely, given h, and h(x),it is infeasible to find any preimage x such that x
=
h(x).
2nd-preimage resistance it is computationally infeasible to find any second
input
that has the same output as any specified input. Namely, given h, x, and h(x),
it is computation infeasible (at a practical level) to find any x' such that
x' _
h(x).
Examples of secure hash functions are Message Digest 5 (MD5) and Secure Hash
Algorithm (SHA-1).
The simplest authentication protocol that uses hash functions is the
UNIXpassword
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.
To verify,
an unverified claimant provides (C,p) and the server first computes h(p ), and
then
CA 02483989 2004-10-26
WO 03/093923 PCT/IB03/03301
21
compares h(p) with the stored h(p) associated with C. If h(p) = h(p), then the
claimant is verified. Otherwise, the claimant is rejected.
This authentication protocol is useful since the verifier does not store the
private
password, p. It only stores h(p) where it is infeasible to find p from h(p),
by the
preimage resistance property of secure hash functions. However many
insecurities
exist in this protocol. The most devastating attack on Unix passwords is the
replay
attack whereby an eavesdropper, somehow gains (C,p), and can "replay" the
authentication protocol.
To protect against replay attacks, Lamport created the Secure Hash Function
One-
Time Passwords protocol, whereby a password cannot be used twice. The scenario
is
as follows: the claimant and verifier decide on a fixed value t and iterator
i, and i,
To start the verifier and claimant set iõ = i, = 0. Next the claimant sends
h%p) = h(-h(h(p))
t-times
to the verifier. The verifier now holds (C, i,,, ht(p)) while the claimant
holds (C, ic, p).
To verify, the claimant sends (ia, ht-t (p)). The verifier verifies if hi`(ht-
Zc(p)) = ht(p)
and checks that is > i,,. If both are true the verifier accepts and sets i, =
is + 1.
Otherwise the verifier rejects and leaves it unchanged.
When i = t - 2, the claimant and verifier must reinitialize, or refresh, by
the claimant
first authenticates him/herself with the verifier and establishing a private
channel.
Once the private channel is created the claimant creates a new p' and sends
ht(p) to
the verifier. Finally, both the claimant and verifier implicitly reset is = iõ
= 0.
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,ht-`(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,ht-'(p)).
If one allows for the claimant and verifier to share a secret, p, then the
protocol can be
simplified so that the claimant sends (C,n, h(n! p)), where I is concatenation
and n is a
CA 02483989 2004-10-26
WO 03/093923 PCT/IB03/03301
22
nonce. (A nonce is a value used no more than once for the same purpose, like
an
incrementor or a random number). However, if the server one verifier is
attacked and
compromised, then the attacker can impersonate the claimant on every other
server.
Ideally, to prevent forced delay attacks one can combine the use of random
numbers with short response times or timestamps plus appropriate additional
techniques. The unique protocol of the present invention does just that and as
a result
provides protection against both replay and forced delay attacks.
A New Non-Interactive Authentication Protocol
The authentication protocol used by the present invention preferably uses
biometric
information, random numbers, a clock with bounded drift and an iterator while
storing
no biometric information with the verifier. In this case the claimant is the
Biotoken
100 and the verifier is the CAS server 205.
Variables
C the public userid of the claimant.
cc, cõ resettable public clocks stored by the claimant and verifier
respectively. The
claimant's clock is has a drift d for every one million ticks. In the
preferred
embodiment, the system clock would be incremented every second. The
clocks, cc, c,,, are set to increments every 32 = 25 seconds and is modulo 2"
64 = 26 units. Namely in code, if c is a system clock incrementing every
second, we check and cc = cC then we every 32 seconds of c is c >> 5 and
modulo 64 means just the first 6 bits. Therefore cc =cC with respect to a
unresettable clock c incrementing by seconds is,
cC = ((c>>5) & Ox3f);
If c cannot be reset to 0 then to reset cC, we take an instance of c, namely c
=
instance at the time of reset and cC will be
cC = (((c-instance)>>5) & Ox3f);
i,, iõ public counters stored by the claimant and verifier respectively.
CA 02483989 2004-10-26
WO 03/093923 PCT/IB03/03301
23
r, a secret 128-bit random number stored by the claimant.
r a 32-bit nonce (random number or incrementor) stored by both the claimant
and
verifier.
b secret biometric information, i.e. the template stored on the biotoken.
h a public secure hash function.
t a public threshold before refreshing. In this case t=210=1024
Variable with primes, such as r'are considered to be of the same type, in this
case r,
but it is unknown if they are equal, i.e. if r 'c = r,
Using this encryption scheme, the biotoken could be initialized by performing
the
following steps:
1. The claimant creates random numbers, r and rC. 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.
2. The claimant prepares h`(bJrc).
3. The claimant and verifier create an authenticated and private channel to
communicate securely without the use of the biotoken.
4. The claimant sends ht(blrc) and r to the verifier.
5. The verifier and claimant implicitly reset cc = cv = -c = `iv = 0.
In this implementation, the claimant already has secret information on the
biotoken,
namely the fingerprint template, b. If the biotoken is somehow physically
compromised then one could impersonate the verifier. For this reason, physical
security measures could be provided to prevent physical intrusion, such as
sealing the
enclosure around the token or other measures. Furthermore, additional "secret
CA 02483989 2004-10-26
WO 03/093923 PCT/IB03/03301
24
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 h1(blrr),h2(blr"), . . ., h-
'((blr,) on the.
device as a nice time/space trade off to speed up verification and preserve
battery life.
Because typing in a full hash decreases usability, it may be preferable to
store and
transport "folded" hashes. See A Note on Hash Sizes for more information on
XOR
folding.
Verification
The claimant (in this case, the Bioktoken) is assumed to have (C, i, c,, r',
r'c, b ), and
it is unknown if the claimant truly is C. The verification procedure is as
follows:
1. The claimant hashes h'-c(b'Jr 1).
2. The claimant sends (C,ic,cc,h`-` (b'Jr'c) +$ h(cclr')).
3. The claimant increments ic.
4. Upon reception, the verifier checks the following conditions. If all are
correct, the claimant is verified.
(a) The verifier compares the time cõ with cC if it is within
acceptable drift the verifier continues, otherwise it rejects. See
A Comment on Time Drift, for more information.
(b) The verifier checks that iy S i,.
(c) The verifier calculates h.' (h'"c(b)re)) = h'(b)rr) and h(cc`r), and
checks if the following is equal:
ht(bfrc) s, h( Jr) = I(hh-:c (' )) (r~
This is true when r = r', b = b' and rr = r 'c with certainty, and
otherwise, it is true with probability 1/2t, where 1 is the length
of the hash.
If one or more of the above fails, the verifier rejects.
CA 02483989 2004-10-26
WO 03/093923 PCT/IB03/03301
5. Once verified that verifier sets i,, = i, + 1.
Refresh
In the preferred embodiment, refresh occurs before i, = t - 1 or iõ = t - 1.
The refresh
process is identical to the reinitialization but the authentication in step 3
is done via
the verification procedure just described.
Benefits of the New Protocol
In this section we briefly discuss the benefits of this protocol for use with
the
biotoken. We claim that the above protocol protects against replay attacks and
forced
delay attacks within an arbitrary timeframe. No biometric information is
stored on the
server. In general, this protocol protects against a compromised verifier from
compromising the claimant and other verifiers, also it protects against a
variety
malicious attacks by the claimant. Finally, due to the one-timeness of the
protocol
eavesdropping strategies are reduced to breaking the hash function or a forced
delay
attack within the timeframe.
However, for this protocol to be considered secure, we must first perform an
internal
audit, next find knowledgeable researchers verify the integrity of the
protocol and
finally publish the protocol publicly so that the security is in the
mathematics rather
than the secrecy of the protocol.
Time Drift
In order to implement this process probably, it is important to configure the
clocks
and time drift to provide the smallest acceptable timeframe with a give drift
d and
clock modulus 2n.
In the preferred embodiment, the server will receive the n-bit clock value c,
from the
claimant and must confirm it is within an acceptable timeframe. To do so, the
verifier
compares the value c, with the lower bound, b1= cv(1-d/l000000) (mod 2") and
the
upper bound b1= c,,(1 +d/1000000) (mod 2'). If b1 <_ b2 then the following
must hold:
CA 02483989 2004-10-26
WO 03/093923 PCT/IB03/03301
26
bl :5 cc .5 b2-
If b1 > bz then the following must hold:
bi :~ cv C 2" .- 1, or
0 cy :-~ b2=
If the above mxadition is true then the serifier accepts, otherwise it
rejects.
For n = 6 (26 = 64, used previously), and d = 53 as per the nicrolynx document
one would check as
follows:
Lox accept 0 /* 0 alse, oche ise true.
bi - ((c-iustance) (int) 4Cc-an~t ace3 )/tO0CO00 0))h64':
b2 = (Cc-instance) + (int)((- a -tance)*53>/3GOQQQti,O))', 64;
accept = C C (tai <= b2) ds& (o >- bi) l (cC <- b2) ) 1'E
C (bi > b2) (C cC >= bi 'It ( cc <= b2))) )
where C - inetauce = CV.
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, valid for? At most a
clock
value c, is valid for
x c clock tick.
1000000
For example, if a clock tick is every 25 = 32 seconds, d = 53, c, = 86400 (32
days)
then the valid timeframe would be about 9 clock ticks (less than 5 minutes).
Note this
is a worst case scenario, one would expect a realistic answer to be about 2.5
minutes
since the probability a given c, in this example is valid after 2.5 minutes is
less than
one half. It goes without saying that a smaller d value could be used to make
these
bounds better.
Secondly, how well can an adversary guess a valid clock value CA? This is both
dependent on d and ii. Let d(bl, b2) be the distance between b1 and b2 be
defined as:
db b) f 6a_bi if bt< 42
1 2n-~b3-bl) ifb,>
Once the distance between b1 and b2 is greater than 2r-1, then an adversary
has a "good
chance" (probability > 2) of guessing a valid CA.
In general, the probability an adversary can guess a valid cA is
Pr (cat is uatidl = d(bl`bz)
CA 02483989 2004-10-26
WO 03/093923 PCT/IB03/03301
27
For this reason, to make these bounds better, a smaller d value could be used,
or as is
used in the preferred embodiment, a larger n value, since increasing n will
decrease
the likelihood of guessing exponentially.
A Note on Hash Sizes
In one embodiment, the verification procedure involves sending a 236 bit
value. This
value is preferred solely for usability purposes. The clock value, c,, takes 6
bits, the
counter, i, takes 10 bits and that leaves 20 bits for the hash value. Again,
these are not
fixed by ay means but instead represent one approach to this problem while
maintaining usability. In such a case, a "random" guess would be at least a
"one-in-a-
million" chance of being correct. Since hashes are typically 128 or 160 bits
long,
however, the number of bits could be modified substantially to reflect high
security
(or lower security) applications.
In order to use "typical" hash values in the present invention, an "XOR fold"
could be
used to preserve the hard core predicate in the hash. To do so we redefine the
hash as
h '(x) h{ (z)1,
where h is the original hash function and f : {0, 1}" -> {0,1}20 defined as
mapping x =
xo,xl, ... , xm-1 bits toy = yo,yl, . . . , y19 bits by
for i = 0, ..., 19. For [ nZ ] x 20 + i > in, then x[ a ] x20+t= 0. As an
example SHA-1
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,
CA 02483989 2004-10-26
WO 03/093923 PCT/IB03/03301
28
int getBit(int i, inc xC53) 'C
return C. x[(i/32)3 ) dt ( Ox1 << (4132) >11aO;
}
void xorGneTo$it(int i, int *v31) {
*val, '- Oxi. < 1;
}
int 1( int x (5] ) {
mt i,y;
for ti=a; i<if 0; if+) {
(geta t ( i , x ) )
xor0nsToBit (J,2O, ty)
3r
return y;
3.
be more terse,
it f C ut x ES)) {
i.nt i,y
for (i-0; i<1$O; i++)
if ( x[(i/32)] . (Oxl << (1%32)) ?
Y " Oxi' << i%20,
return y;
To change this for MD5, one need only loop to 128 and the input would be x
[4]. In
the preferred embodiment of this step, both h`-"(b) and (hcjr) are folded
independently and are then XOR'ed together.
Referring now to Figure 11, an alternative method for initializing a biotoken
is
shown. The first step 1100 of the method involves creating and storing a
biometric
image. 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.
CA 02483989 2004-10-26
WO 03/093923 PCT/IB03/03301
29
The image or template is then used to compare with data that is captured at a
later
time. The value received by the CAS server 205 is decrypted 1145 and the
unique
value assigned to the biotoken is extracted from the decrypted value and
compared
1150 with the shared secret on the CAS server 205. The remaining portions of
the
number (representing a hash value of the consistent template elements) are
then
extracted 1155 and stored 1160 under the user in the event that later
verification (or
reverification) is required.
Referring now to Figure 12, a flowchart for using a biotoken using an
alternative method is shown. The first step of the method involves capturing a
biometric image or template 1205, 1210. The image or template is then used to
compare with data that is stored on the biotoken. Again, the consistent
template
elements are extracted 1215 and compared to stored values. In the default
case, the
comparison is between the hash 1220 of the captured value and the stored 1225
hash
value. Alternatively, the captured has value could be hashed and used without
comparing to the stored value. In either event, the captured (or stored)
finger has
value is combined with a counter value 1230 (that is incremented on each use)
and the
pre-shared secret 1235 and collectively the numbers are once again hashed
1240. If
manual entry is expected, some portion of that value is extracted 1245(the
process for
defining which portions are used must be defined) and is either displayed 1250
or
otherwise transmitted 1250. The same process is performed during validation on
the
CAS server 305. The stored hash value 1255, a counter 1260, and the shared
secret
1265 are combined and hashed 1270 and a portion of those values are extracted
1275
are compared 1280 to the transmitted values. This process is repeated after
incrementing the counter until a threshold is reached. If there is no match,
then
authentication (or process of the request) is denied 1285. If a match is
successful
1290, then the authentication request (or other process request) is validated
and is sent
for processing. In 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.
CA 02483989 2004-10-26
WO 03/093923 PCT/IB03/03301
While the description above included references to this combined system, each
component may also be used individually and it is the expectation of the
applicants
that such components will be used in a number of difference environments in
this
manner. As such, the scope of the claims should not be interpreted to require
such
related but distinct components. Additionally, while this invention will often
make
use to biometric identification, any other form of identification could be
used. For
example, a chip or other electronics could be embedded under a human's skin
and
used to provide a unique identifier for such person. In the case of animals,
this could
include a tag or other form of ID on the ear. As such, biometric data should
not be
construed as a limitation of the claims. Finally, while the authentication
step of the
method and authentication server of the system have often been described with
reference to a computer or networked system, any system that includes or has
access
to the authentication server (even if just running on a local device or
machine) could
be adapted to receive and confirm the transmitted password, challenge phrase
or ID.
For these reasons, the claims should not be limited by these embodiments but
should
instead be interpreted in accordance with the following claims.
