(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT)
`
`(19) World Intellectual Property
`Organization
`International Bureau
`
`(43) International Publication Date
`17 June 2004 (17.06.2004)
`
`
`
`PCT
`
`(10) International Publication Number
`
`WO 2004/051585 A2
`
`(51) International Patent Classification7:
`
`G07F 7/10
`
`(21) International Application Number:
`PCT/USZOO3/037928
`
`(22) International Filing Date:
`26 November 2003 (26.11.2003)
`
`(25) Filing Language:
`
`(26) Publication Language:
`
`English
`
`English
`
`(30) Priority Data:
`60/429,754
`
`27 November 2002 (27.11.2002)
`
`US
`
`(71) Applicant: RSA SECURITY INC [US/US]; 174 Middle—
`sex Turnpike, Bedford, MA 01730 (US).
`
`(72) Inventors: JAKOBSSON, Markus; 1203 Garden Street,
`Hoboken, NJ 07030 (US). JUELS, Ari; 131 Freeman
`Street, Brookline, MA 02446 (US). KALISKI, Burton,
`5., Jr.; 22 Pembroke Road, Wellesley, MA 02181 (US).
`
`(74) Agent: PRAHL, Eric, L.; Hale and Dorr LLP, 60 State
`Street, Boston, MA 02109 (US).
`
`(81) Designated States (national): AE, AG, AL, AM, AT, AU,
`AZ, BA, BB, BG, BR, BW, BY, BZ, CA, CH, CN, CO, CR,
`CU, CZ, DE, DK, DM, DZ, EC, EE, EG, ES, FI, GB, GD,
`GE, GH, GM, HR, HU, ID, IL, IN, IS, JP, KE, KG, KP, KR,
`KZ, LC, LK, LR, LS, LT, LU, LV, MA, MD, MG, MK, MN,
`MW, MX, MZ, NI, NO, NZ, OM, PG, PH, PL, PT, RO, RU,
`SC, SD, SE, SG, SK. SL, SY, TJ, TM, TN, TR, TT, TZ, UA,
`UG, UZ, VC, VN, YU, ZA, ZM, ZW.
`
`(84) Designated States (regional): ARIPO patent (BW, GH,
`GM, KE, LS, MW, MZ, SD, SL, SZ, TZ, UG, ZM, ZW),
`Eurasian patent (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM),
`European patent (AT, BE, BG, CH, CY, CZ, DE, DK, EE,
`ES, FI, FR, GB, GR, HU, IE, IT, LU, MC, NL, PT, RO, SE,
`SI, SK, TR), OAPI patent (BF, BJ, CF, CG, CI, CM, GA,
`GN, GQ, GW, ML, MR, NE, SN, TD, TG).
`
`Published:
`
`without international search report and to be republished
`upon receipt of that report
`
`For two-letter codes and other abbreviations, refer to the ”Guid—
`ance Notes on Codes and Abbreviations ” appearing at the beg in—
`ning of each regular issue ofthe PCT Gazette.
`
`(54) Title: IDENTITY AUTHENTICATION SYSTEM AND METHOD
`
`(57) Abstract: A method and system for generating an authentication code that depends at least in part on a dynamic value that
`changes over time, an event state associated with the occurrence of an event, and a secret associated with an authentication device.
`By generating the authentication code responsive to an event state, an identity authentication code can be used to verify identity and
`to communicate event state information, and to do so in a secure manner.
`1
`
`Apple 1113
`
`
`
`2004/051585A2||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||1
`
`

`

`WO 2004/051585
`
`PCT/U52003/037928
`
`IDENTITY AUTHENTICATION SYSTEM AND METHOD
`
`Cross Reference to Related Applications
`
`[0001]
`
`This application claims the benefit under 35 U.S.C. § 119(e) ofU.S. Provisional
`
`Application No. 60/429,754, filed November 27, 2002.
`
`Field of the Invention
`
`[0002]
`
`The invention relates generally to the fields of cryptography and security. More
`
`specifically, the invention relates to the generation and verification of identity authentication
`
`codes.
`
`Background of the Invention
`
`10
`
`15
`
`20
`
`[0003]
`
`Generally, security systems employ identity-based authentication schemes to verify
`
`the identity of an entity that is allowed access to a physical location or object, in the case of a
`
`physical security system, or electronic access to a computer system or data, in the case of a data
`
`security system. One goal of such security systems is to accurately determine identity so that an
`
`unauthorized party cannot gain access. Security systems can use one or more of several factors,
`
`alone or in combination, to authenticate entities. For example, identification systems can be
`
`based on something that the entity knows, something the entity is, or something that the entity
`
`has.
`
`[0004]
`
`Examples of something an entity knows are a code word, password, personal
`
`identification number (“PIN”) and the like. One exemplary computer-based authentication
`
`method involves the communication of a secret that is specific to a particular entity or user. The
`
`entity seeking authentication transmits the secret or a value derived from the secret to a verifier,
`
`which authenticates the identity of the entity. In a typical implementation, an entity
`
`

`

`WO 2004/051585
`
`PCT/U52003/037928
`
`communicates both identifying information (e.g., a user name) and a secret (e.g., a password) to
`
`the verifier. The verifier typically possesses records that associate a secret with each entity. If
`
`the verifier receives the appropriate secret for the entity, the entity is successfully authenticated.
`
`If the verifier does receive the correct secret, the authentication fails.
`
`[0005]
`
`Examples of something the entity is include characteristics that are unique to people,
`
`such as physical, biological, and psychological characteristics (referred to generally here as
`
`biological characteristics), such as fingerprints, handwriting, eye retina patterns, and face, body,
`
`and organ appearance, size and shape. Suitable biological characteristics typically are not under
`
`the control of the person, and are therefore difficult for anyone besides the intended person to
`
`present, because, in part, they are difficult to replicate. The verifier typically can observe the
`
`characteristic, and compare the characteristic to records that associate the characteristic with the
`
`entity. The observation of biological characteristics is referred to generally as biometric
`
`measurement.
`
`[0006]
`
`An example of something an entity possesses is a physical or digital object, referred
`
`to generally as a token, that is unique, or relatively unique, to the user. A simple example is a
`
`conventional metal key for use in a door. Possession of the door key in effect authenticates the
`
`user to the lock and allows entry. Similarly, possession of a token such as a bank card having
`
`certain specific physical and electronic characteristics, for example containing a specific
`
`identification number that is revealed when the token is accessed in a particular manner, can be
`
`this type of factor. A token containing a computing device that performs encryption using an
`
`encryption key contained in the device would also be regarded as this type of factor. For
`
`example, a token could accept user input, which might include a PIN or a challenge value, and
`
`provide as output a result encrypted With a secret encryption key stored in the card. The verifier
`
`can then compare the output to an expected value in order to authenticate the entity.
`
`10
`
`15
`
`20
`
`

`

`WO 2004/051585
`
`PCT/U82003/037928
`
`[0007]
`
`A token might also, or alternatively, use additional input information, such as time, or.
`
`a counter, for example, such that the result changes over time but is deterministic to an entity that
`
`possesses a secret (e.g., a value known only by the token and the verifier), but not predictable by
`
`an observer who does not possess the secret. These systems generally perform some
`
`computation using a stored secret as input to generate an authentication code that is used to
`
`authenticate the entity. Some systems are time-based, in that they use a time-based dynamic
`
`variable to calculate a non-predictable authentication code that ultimately authenticates the
`
`entity. Here, “non—predictable” means that the authentication code is not predictable by a party
`
`that does not know the associated secret, the algorithm for calculating the code, or both. One
`
`10
`
`15
`
`example, US. Patent No. 5,937,068 entitled “System and Method for User Authentication
`
`Employing Dynamic Encryption Variables,” uses as input a combination or subset of three
`
`variables: the current time, the number of access requests made by the card, and a “secret
`
`dynamic encryption key” that is updated with each access request. The token, in this case, also
`
`verifies a PIN entered by the user before communicating an authentication code.
`
`[0008]
`
`Although the dynamic nature of the authentication codes generated by such an
`
`approach avoids problems inherent with using fixed authentication codes, an unattended or
`
`stolen token remains vulnerable to attack. Would-be attackers who gain access to tokens can
`
`subject the tokens to sophisticated analysis intended to determine their methods of operation,
`
`and/or the secret(s) stored within. Attackers might inspect the token and conduct such analysis
`
`in order to determine the associated secret, the algorithm for calculating the authentication code,
`
`or both. The attacker might then be able to generate apparently valid authentication codes in
`
`order to illegally gain physical or electronic access to secured areas or systems. Many tamper-
`
`resistant hardware designs are available, however, new attacks are frequently developed to
`
`thwart tamper resistance. Further, current tamper resistant designs do not provide verifiers,
`
`

`

`WO 2004/051585
`
`PCT/U82003/037928
`
`authentication systems, system administrators, or another relevant authority with any indication
`
`that the token has been tampered with.
`
`[0009]
`
`One approach to detection of tampering is described in Johan Hastad, Jakob Jonsson,
`
`Ari Juels, Moti Yung, “funkspiel schemes: an alternative to conventional tamper resistance”,
`
`ACM Conference on Computer and Communications Security 2000; 125—133. Hastad et al.
`
`describe several “funkspiel schemes” whereby a device can indicate to a verifier that tampering
`
`has occurred, without revealing to an adversary Whether the tampering has been detected. The
`
`schemes are oriented toward the generation of a sequence of message authentication codes,
`
`Where the message authentication may fail after tampering has been detected. In one example
`
`given, the message authentication code is embedded into a digital signature scheme, where the
`
`digital signature indicates whether a transaction has been approved by a device, while the
`
`message authentication code indicates whether the device has been tampered with. The message
`
`authentication code itself may not be suitable as an identity authentication code as it is oriented
`
`toward a sequence of message transactions rather than time-based identity authentication. In
`
`particular, Hastad et a1 does not provide any method for efficiently verifying a single
`
`authentication code among those over a very long period of time, without substantial
`
`computation by the verifier (e. g., a potentially long chain of function evaluations), substantial
`
`computation by both parties (e. g., asymmetric encryption) or substantial storage by both parties
`
`(e. g., many one-time bits).
`
`Summary of the Invention
`
`10
`
`15
`
`20
`
`[0010]
`
`The invention addresses these shortcomings by including an indication of the
`
`occurrence of an event directly into the efficient computation of an identity authentication code,
`
`where the verifier may efficiently verify the authentication code and identify the signaling of an
`
`25
`
`event state.
`
`

`

`WO 2004/051585
`
`PCT/U82003/037928
`
`[0011]
`
`While the previous approaches do not have the flexibility to communicate event
`
`information in, or as part of, an authentication code, in the present approach, an authentication
`
`code is generated in a manner that communicates to the verifier information about the occurrence
`
`of one or more reportable events. A reportable event is an event other than events associated
`
`with the normal operation of an authentication method (and that can be reported to the verifier).
`
`Thus, for example, a reportable event would not include an event reporting a request for an
`
`authentication code. A reportable event could be, on the other hand, an event that is at least one
`
`of an anomalous, extraordinary, remarkable, unusual, and the like. A reportable event also could
`
`be any sort of event that can be detected and/or communicated by or to the device. Example
`
`reportable events include: device tampering; an event external to the device detected by the
`
`device; an environmental event, such as temperature exceeding or falling below a threshold;
`
`static discharge; high or low battery power; geographic presence at a particular location;
`
`confidence level in a biometric reading; and so on. A reportable event may also provide an
`
`indication of the likelihood that the security of the authentication system has been compromised
`
`or the likelihood that the authentication device has or will develop an operational problem (e.g.,
`
`the condition of the authentication device). A reportable event can be the cumulative effect of
`
`multiple past events. A reportable event also can be the device operational status.
`
`[0012]
`
`A reportable event may include information concerning the condition of the
`
`authentication device (cg, tampering, low battery power, etc.), the security of the authentication
`
`system (e.g., strength of a user’s biometric information, accuracy of a PIN entry, verification of
`
`an authentication device signature), the status of the user (e.g., mobile or stationary, network
`
`access location, location in a facility, etc), the location of the device (e.g., region, country, city,
`
`etc.) or the environment where the device is located (e.g., temperature, radiation level, etc.). In
`
`one embodiment, the reportable event directly reports information concerning at least one of the
`
`condition ofthe authentication device, the security of the authentication system, the status of the
`
`10
`
`15
`
`20
`
`25
`
`-5-
`
`

`

`WO 2004/051585
`
`PCT/U82003/037928
`
`user, the location of the authentication device, and the environment where the authentication
`
`device is located.
`
`[0013]
`
`In general, in certain aspects of the invention, a user or a device on behalf of the user,
`
`algorithmically computes an authentication code based on both a dynamic variable (e.g., that
`
`changes over time) and a secret associated with the user or the device. The generated
`
`authentication code is non-predictable to an observer, but is verifiable by a verifier. The
`
`authentication code can also depend, in part, on any other information, for example, on one or
`
`more of a PIN, a password, and data derived from a biometric observation, or information
`
`associated with the user, the authentication device, or the verifier.
`
`[0014]
`
`The security of an authentication system is improved when a device takes specific
`
`action upon the occurrence of a reportable event. In one illustrative example, if an attacker
`
`attempts to disassemble or otherwise tamper with a device, it is useful for the device to signal the
`
`occurrence of such event (once detected by the device) to a verifier by communicating the
`
`device’s event state. In this example, the tampering event has at least two possible event states;
`
`yes — tampering occurred, and no — tampering has not occurred. Other information also can be
`
`communicated, such as information about the type of tampering or information about the time
`
`that the tampering occurred. Other examples of reportable events include environmental events
`
`(e.g., high or low temperature), battery voltage level, and accuracy of PIN or password entry.
`
`[0015]
`
`In one embodiment, the occurrence of an event is communicated explicitly in the
`
`authentication code. For example, one or more bits included in the authentication code can be
`
`dedicated to reporting the occurrence of an event, i.e., reporting the event state (and herein we
`
`refer to event state data as data representing, communicating, or derived from the event state)
`
`Where the event state is information about the state of a device with respect to the occurrence or
`
`non-occurrence of event(s). In another embodiment, the device’s event state can be
`
`communicated implicitly, such that only the device and the verifier can feasibly determine the
`
`10
`
`15
`
`20
`
`25
`
`-5-
`
`

`

`WO 2004/051585
`
`PCT/U82003/037928
`
`event state from the communication. It may be advantageous if an attacker with access to device
`
`is unable to determine if an event was detected and communicated because an unwamed attacker
`
`is more likely to take actions that can lead to observation and apprehension by authorities. In
`
`some embodiments, the device operates differently upon occurrence of an event, such that the
`
`occurrence of the event is communicated in identity authentication codes output by the device
`
`subsequent to the occurrence of the reportable event. This may help discourage copying. For
`
`example, when a device that is providing an alert of an anomalous event is copied, the “clone,”
`
`or copied device will also report the anomalous event.
`
`[0016]
`
`In one embodiment, authentication methods can be incorporated in a hardware device
`
`10
`
`provided to the user, such as a token or a key fob. (Other possibilities are described below.)
`
`Additionally, a device can include a software program for carrying out the method, for example,
`
`as software executing on a general—purpose computer, handheld computer, telephone, personal
`
`digital assistant, and so on, or in some other manner. The device may, in some implementations,
`
`allow the user to input a second secret, such as a PIN, verifier identifier, and so on, in order to
`
`15
`
`generate an authentication code.
`
`[0017]
`
`In general, in one aspect, the invention relates to an authentication device that
`
`generates an identity authentication code by storing an event state in the device, modifying the
`
`event state in response to an event, and generating an authentication code that depends, at least in
`
`part, on a dynamic value (e.g. a time value), the event state, and a secret associated with the
`
`20
`
`device. The authentication device thus produces a different identity authentication code based on
`
`the event state. By comparing a received authentication code to the possible authentication
`
`codes that could be generated by the authentication device, the verifier can not only verify the
`
`identity of the user, but can also determine the event state, and thereby determine whether one or
`
`more events occurred.
`
`

`

`WO 2004/051585
`
`PCT/U82003/037928
`
`[0018]
`
`In some embodiments, the event state is associated with .one or more reportable
`
`events. In some embodiments, the event state is modified in response to a reportable event. In
`
`some such embodiments, the event state is stored in the form of event state data, which reflects
`
`the state of one or more reportable events. The event state data thus can communicate the event
`
`state.
`
`10
`
`15
`
`20
`
`[0019]
`
`In some embodiments, the method is constructed such that it is not possible for an
`
`attacker who has access to the device to determine whether the report of an event was
`
`communicated in the authentication code. As briefly described above, the communication of the
`
`event information can be referred to as “covert.” On the other hand, if some event information
`
`can be deduced by an attacker or observer, then the communication is referred to as “overt.”
`
`Covert communication may be beneficial because it can be used to report the occurrence of an
`
`event without an attacker becoming aware of the report. Overt communication may be beneficial
`
`in that it allows a general observer to become informed about state information. It is possible to
`
`signal some part of an event state in a covert manner, and another part in an overt manner.
`
`[0020]
`
`An implementation of a system for generating an identity authentication code using
`
`event state information can include a data store for storing an event state in an authentication
`
`device, an event recorder for modifying the event state in response to one or more reportable
`
`events, and an authentication code generator for generating an identity authentication code that
`
`depends at least in part on a dynamic value, the event state, and a secret associated with the
`
`device. Such an implementation can be included as either part of an authentication device (e.g.,
`
`a token) or part of a verifier (e.g., a verification computer), or both. For both the device and the
`
`verifier, the system can be implemented as software running on a computer, such as a
`
`microprocessor or other general purpose computer. The system can also be implemented in
`
`hardware, as described above.
`
`

`

`WO 2004/051585
`
`PCT/U82003/037928
`
`[0021]
`
`In general, in another aspect, the verifier receives authentication information that
`
`includes an identity authentication code generated by a device that at least in part depends on
`
`time, a secret associated with the device, and an event state. The verifier verifies the identity of
`
`the user and determines the event state in response to the received identity authentication code.
`
`The verifier can determine whether an event occurred from the event state. The verifier can take
`
`action in response to the determined event state, for example, logging the event state for later
`
`analysis, warning the system administrator or relevant authorities, or providing more limited
`
`access to the location or system than would be granted if a different event state was determined.
`
`The authentication information can also include one or more of a user identifier, a PIN,
`
`password, a biometric reading, and other additional authentication information.
`
`[0022]
`
`In some embodiments, the verifier generates an expected identity authentication code
`
`that depends at least in part on a dynamic value associated with a time period and the event state.
`
`The event state can include an event state secret, described further below, and bits derived from
`
`the event state secret, where one or more bits are associated with a time interval.
`
`[0023]
`
`In general, in another aspect, the invention relates to a system and method for
`
`generating an identity authentication code by, for example, an authentication device and/or a
`
`verifier. Describing first the device, the device stores a first secret value associated with the
`
`authentication device, and a second secret value associated with event state. The device also
`
`generates a dynamic value that changes over time. The device derives from the second value and
`
`the dynamic value event state data associated with a time period. The device derives a value for
`
`a time period from the first value and the event state data. The device then calculates an identity
`
`authentication code using the time-specific value as input. The verifier likewise can implement
`
`these method steps so as to determine one or more possible authentication codes, depending on
`
`the event state data.
`
`10
`
`15
`
`20
`
`

`

`WO 2004/051585
`
`PCT/U82003/037928
`
`[0024]
`
`In one embodiment, the event state data includes bits each associated with a time
`
`period, where the time—specific value is derived from the first value and the respective bit
`
`associated with the time period. In such an embodiment, there are two possible states associated
`
`with a time period, depending on the value ofthe bit. If an event occurs, the bits are modified in
`
`response to the detected event, such that the generated authentication code is the other of the two
`
`possible choices. Optionally, the second secret value (associated with the event state) can also
`
`be modified in response to the detected event, such that later generations of event state bits will
`
`have a different value than normal. The first secret value can be the same as the second secret
`
`value, or they can be different values, or they can partially overlap.
`
`[0025]
`
`In one embodiment, the event state data comprises a number of bits associated with a
`
`respective time period, wherein the time-specific value is derived from the first value and the
`
`number of bits associated With the respective time period.
`
`[0026]
`
`In general, in another aspect, a system for generating an identity authentication code
`
`associated with an authentication device includes an authentication code generator. The
`
`authentication code generator generates an identity authentication code that depends at least in
`
`part on a dynamic value that changes over time, an event state indicative of the occurrence of an
`
`event, and a secret associated with the authentication device. One embodiment of such a system
`
`is implemented as a software program for execution on a processor, such as a microprocessor or
`
`general purpose computer. The system can be included in an authentication device or a verifier,
`
`or in another system.
`
`[0027]
`
`The foregoing and other objects, aspects, features, and advantages of the invention
`
`will become more apparent from the following description and from the claims.
`
`10
`
`15
`
`-10-
`
`

`

`WO 2004/051585
`
`PCT/U82003/037928
`
`Brief Description of the Drawings
`
`[0028]
`
`In the drawings, like reference characters generally refer to the same parts throughout
`
`the different views. Also, the drawings are not necessarily to scale, emphasis instead generally
`
`being placed upon illustrating the principles of the invention.
`
`5
`
`[0029]
`
`FIG. 1 is a block diagram depicting an authentication system including an
`
`authentication device and a verifier according to an embodiment of the invention.
`
`[0030]
`
`FIG. 2 is a block diagram depicting the generation of an authentication code
`
`according to an embodiment of the invention.
`
`[0031]
`
`FIG. 3 is a block diagram depicting the generation of an authentication code
`
`10
`
`according to an embodiment of the invention.
`
`[0032]
`
`FIG. 4 is a block diagram depicting a detailed implementation of the embodiment of
`
`FIG. 3.
`
`[0033]
`
`FIG. 5 is an example demonstrating the use of event state data in generating an
`
`authentication code.
`
`15
`
`[0034]
`
`FIG. 6 is a flowchart depicting an embodiment of a method for generating an
`
`authentication code.
`
`[0035]
`
`FIG. 7 is a block diagram depicting the generation of an authentication code
`
`according to an embodiment of the invention.
`
`[0036]
`
`FIG. 8 is a block diagram depicting the generation of an authentication code
`
`20
`
`according to an embodiment of the invention.
`
`Detailed Description
`
`[0037]
`
`Referring to FIG. 1, in one embodiment of an authentication system 100 according to
`
`the invention, a verifier 105, is used to help securely authenticate the identity of exemplary user
`
`110. As used here, “authenticate” means to verify the identity of a user, and so “authenticate”
`
`25
`
`and “verify” can be used interchangeably throughout. Also, although the specification will
`
`-11-
`
`

`

`WO 2004/051585
`
`PCT/U82003/037928
`
`discuss, for simplicity, authentication of “users,” it should be understood that “users” means any
`
`entity requiring authentication such as, for example, a person, animal, device, machine, or
`
`computer. The inclusion of a single user 110 is exemplary, and typically a verifier 105 will be
`
`used to verify a large number of users 110. Similarly, the inclusion of a single verifier 105 is
`
`exemplary, and typically a user 110 can have an authentication attempt verified by one or more
`
`of a large number of verifiers 105. In some embodiments, a single verifier 105 is able to verify a
`
`user 110, while in other embodiments, two or more verifiers 105 are together required to perform
`
`this task.
`
`[0038]
`
`The verifier 105 can be any sort of device that implements the functions described
`
`here. In one embodiment, the verifier 105 is implemented as software running on a server class
`
`computer including a processor, memory, and so on, to enable authentication of a large number
`
`of users, for example, in an enterprise. The verifier 105 can also be implemented as software
`
`running on a desktop computer, laptop computer, special-purpose device, or personal digital
`
`assistant (PDA). For example, the verifier 105 can be implemented as a software program
`
`running on a general-purpose computer, possibly interacting with one or more other computer
`
`programs on the same or a different computer. Some or all of the verifier 105 functionality can
`
`be implemented in hardware, for example in an Application Specific Integrated Circuit (ASIC)
`
`and the like. In still further embodiments, the verifier 105 can be implemented in a cellular
`
`telephone, or specialized hardware embedded in a cellular telephone and adapted to interact with
`
`the cellular telephone’s circuitry. Other sizes, shapes, and implementations are possible without
`
`departing from the spirit of the invention.
`
`[0039]
`
`Authentication can result in the performance of one or more actions including,
`
`without limitation, providing access or privileges, taking action, or enabling some combination
`
`of the two. Access includes, without limitation: access to a physical location, communications
`
`network, computer system, and so on; access to such services as financial services and records,
`
`10
`
`15
`
`20
`
`25
`
`-12-
`
`

`

`WO 2004/051585
`
`PCT/U82003/037928
`
`health services and records and so on; or access to levels of information or services. The user
`
`110 and the verifier 105 can be physically near one another or far apart.
`
`[0040]
`
`As illustrated, a user 110 can communicate with a user authentication device 120.
`
`The user authentication device 120 provides information used to authenticate the user 110. The
`
`user authentication device 120 can optionally provide a user interface 130. Communication
`
`between the user 110 and the user authentication device 120 can take place via this user interface
`
`130. The user interface 130 can provide an input interface, an output interface, or both. An
`
`input interface enables the user 110 to communicate information to the user authentication
`
`device 120. The input interface can be any mechanism for receiving user input, and can include,
`
`without limitation: a keypad or keyboard; one or more push buttons, switches or knobs; a touch
`
`sensitive screen; a pointing or pressing device; a trackball; a device for capturing sound, voice or
`
`handwriting; a device for capturing biometric input (such as a fingerprint, retina or voice
`
`characteristic); and so forth. An output interface enables the user authentication device 120 to
`
`communicate information to the user 110 and can be any mechanism for communicating to a
`
`user, including, without limitation: a visual display to support alphanumeric characters or
`
`graphics such as a LCD display or LED display; an electrophoretic display; one or more light
`
`sources; a loudspeaker, a sound or voice generator; a Vibration interface; and so forth. In some
`
`embodiments, the user 110 provides, via the user interface 130, identifying information (such as
`
`a user identifier, PIN, or password, or a biometric characteristic such as a fingerprint, retina
`
`pattern, or voice sample), or possessions (such as physical keys, digital encryption keys, digital
`
`certificates, or authentication tokens) to the user authentication device 120.
`
`[0041]
`
`The user authentication device 120 can take various forms in various embodiments of
`
`the invention, provided that the user authentication device 120 performs the functions required of
`
`the user authentication device 120 for secure authentication. The user authentication device 120
`
`can be implemented in packages having a wide variety of shapes and form factors. For example,
`
`10
`
`15
`
`20
`
`25
`
`-13-
`
`

`

`WO 2004/051585
`
`PCT/U82003/037928
`
`the user authentication device 120 can be a credit—card sized and shaped device, or can be much
`
`smaller or much larger. One credit—card sized embodiment of the user authentication device 120
`
`includes a microprocessor with on-board memory, a power source, and a small LCD display.
`
`The embodiment optionally includes a keypad or buttons for PIN entry, entry of authentication
`
`information requests, or for other entry or interaction with the device 120. In another
`
`embodiment, a credit-card sized device 120 includes a processor with on-board memory that is
`
`used as a “smart card,” that can be installed into another device that provides power and/or
`
`interface. In still other embodiments, a credit-card sized device 120 is a card such as a credit
`
`card including a magnetic strip or other data store on one of its sides. In other embodiments, the
`
`user authentication device 120 is a “key fob,” that is, a smaller device with a display and battery
`
`that is sized and shaped to fit on a key ring. In yet another embodiment, the user authentication
`
`device 120 is a peripheral device that communicates with a computer, telephone, or other device,
`
`such as a USB dongle. In still other embodiments, the user authentication device 120 can be a
`
`desktop computer, laptop computer, or personal digital assistant (PDA). For example, the
`
`authentication device 120 can be implemented as a software program running on a general-
`
`purpose computer, possibly interacting with one or more other computer programs on the same
`
`or a different computer. In still further embodiments the user authentication device can be a
`
`cellular telephone, or specialized hardware embedded in a cellular telephone and adapted to
`
`interact With the cellular telephone’s circuitry, such as a SIM card. In this example and in others,
`
`the