(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2004/0172535 A1
`JakobSS0n et al.
`(43) Pub. Date:
`Sep. 2, 2004
`
`US 2004O172535A1
`
`(54) IDENTITY AUTHENTICATION SYSTEM AND
`METHOD
`
`(75) Inventors: Markus Jakobsson, Hoboken, NJ (US);
`Ari Juels, Brookline, MA (US); Burton
`S. Kaliski JR., Wellesley, MA (US)
`Correspondence Address:
`TESTA, HURWITZ & THIBEAULT, LLP
`HIGH STREET TOWER
`125 HIGH STREET
`BOSTON, MA 02110 (US)
`
`(73) Assignee: RSA Security Inc., Bedford, MA
`(21) Appl. No.:
`10/724,034
`
`(22) Filed:
`
`Nov. 26, 2003
`
`Related U.S. Application Data
`(60) Provisional application No. 60/429,754, filed on Nov.
`27, 2002.
`
`Publication Classification
`(51) Int. Cl. ................................................... H04L 9/00
`(52) U.S. Cl. .............................................................. 713/168
`(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.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`DEVICE DATA235
`
`-
`
`v
`
`A.
`
`VERIFER
`IDENTIFEER
`
`N
`
`- - - - - - - - - - - - - -
`
`SECRET
`(K)
`
`DYNAMIC VALUE
`(T)
`
`EVENT STATE (E)
`
`COMBINATION
`FUNCTION
`
`230
`
`
`
`AUTHENTCATION CODE
`m
`
`290
`
`A (K, T, E)
`92
`A (K, T, E, P)
`A (K, T, E, P, ... N, W, ...). 293
`
`
`
`
`
`:
`
`(N)
`
`p";
`
`IPR2018-00067
`Unified EX1024 Page 1
`
`

`

`Patent Application Publication Sep. 2, 2004
`
`Sheet 1 of 8
`
`US 2004/0172535 A1
`
`00||
`
`
`
`
`
`
`
`
`
`?
`
`IPR2018-00067
`Unified EX1024 Page 2
`
`

`

`Patent Application Publication Sep. 2, 2004
`
`Sheet 2 of 8
`
`US 2004/0172535 A1
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`(L)
`
`? ? ? ? ? ? ?(>)
`
`LENJOES
`
`
`
`
`
`(E) ELVIS LNBAE
`
`.; = nTVA
`
`|(N)}
`NOLLVHEN=9 | !|
`||
`]J
`
`IPR2018-00067
`Unified EX1024 Page 3
`
`

`

`Patent Application Publication Sep. 2, 2004
`
`Sheet 3 of 8
`
`US 2004/0172535 A1
`
`
`
`
`
`??£
`
`
`
`LERHOES LINEAE
`
`?55
`
`LERHOES E OIAEG
`
`EGIOO
`
`Õ55
`
`IPR2018-00067
`Unified EX1024 Page 4
`
`

`

`Patent Application Publication Sep. 2, 2004 Sheet 4 of 8
`
`US 2004/0172535 A1
`
`
`
`
`
`(Lowd: Jox SB) =°×
`
`
`
`(£GVAJ JOX SE) *= = SLIGEX
`
`
`
`(SE) LEHOES
`
`_LNE/NE
`
`?V?
`
`
`
`) »
`
`A\/O
`
`
`
`(zowd- uox s?)*3= Sa
`
`__---,
`
`
`
`
`
`
`
`
`
`
`
`
`
`((L) LIGE 'Lººy) 6 = HnOHX
`
`IPR2018-00067
`Unified EX1024 Page 5
`
`

`

`Patent Application Publication Sep. 2, 2004
`
`Sheet 5 of 8
`
`US 2004/0172535 A1
`
`TOO
`
`NO||LOV/ 9 NWT
`
`Z NINT TOO
`
`EO|/\EC] | NWT TOO
`
`LERHOES
`
`
`
`
`
`
`
`ve
`
`CN
`
`- - -
`
`co
`
`V
`
`O
`
`O
`
`N
`
`IPR2018-00067
`Unified EX1024 Page 6
`
`

`

`Patent Application Publication Sep. 2, 2004 Sheet 6 of 8
`
`US 2004/0172535 A1
`
`
`
`
`
`
`
`IPR2018-00067
`Unified EX1024 Page 7
`
`

`

`Patent Application Publication Sep. 2, 2004
`
`Sheet 7 of 8
`
`US 2004/0172535 A1
`
`
`
`
`
`
`
`IPR2018-00067
`Unified EX1024 Page 8
`
`

`

`Patent Application Publication
`
`Sep. 2, 2004
`
`Sheet 8 of 8
`
`
`
`|--------------------------+ 0~ | ? ºS
`
`* ~ - - ---- ? • <== ~ ~
`
`|
`
`| |
`
`Z! 8
`
`IPR2018-00067
`Unified EX1024 Page 9
`
`

`

`US 2004/0172535 A1
`
`Sep. 2, 2004
`
`IDENTITY AUTHENTICATION SYSTEMAND
`METHOD
`
`CROSS REFERENCE TO RELATED
`APPLICATIONS
`0001) This application claims the benefit under 35 U.S.C.
`S 119(e) of U.S. Provisional Application No. 60/429,754,
`filed Nov. 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 authen
`tication codes.
`
`BACKGROUND OF THE INVENTION
`Generally, security systems employ identity-based
`0.003
`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 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 char
`acteristics that are unique to people, Such as physical,
`biological, and psychological characteristics (referred to
`generally here as biological characteristics), Such as finger
`prints, handwriting, eye retina patterns, and face, body, and
`organ appearance, Size and shape. Suitable biological char
`acteristics 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 characteris
`tic, and compare the characteristic to records that associate
`the characteristic with the entity. The observation of bio
`logical 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 encryp
`tion 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.
`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 asso
`ciated Secret, the algorithm for calculating the code, or both.
`One example, U.S. Pat. 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 unat
`tended 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 meth
`ods of operation, and/or the Secret(s) stored within. Attack
`erS 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 authentica
`tion 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,
`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 Håstad, Jakob Jonsson, Ari Juels, Moti
`Yung, “funkSpiel Schemes: an alternative to conventional
`tamper resistance', ACM Conference on Computer and
`Communications Security 2000; 125-133. Håstad 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
`
`IPR2018-00067
`Unified EX1024 Page 10
`
`

`

`US 2004/0172535 A1
`
`Sep. 2, 2004
`
`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, Håstad et al does not
`provide any method for efficiently verifying a single authen
`tication 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
`0.010 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 authenti
`cation code and identify the Signaling of an event State.
`0.011
`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 commu
`nicates 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 authen
`tication 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 con
`cerning the condition of the authentication device (e.g.,
`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 of the authentication device, the
`Security of the authentication System, the Status of the user,
`the location of the authentication device, and the environ
`ment 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 infor
`mation 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 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 com
`municated because an unwarned 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 authen
`tication codes output by the device Subsequent to the occur
`rence 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 provided to the user, Such
`as a token or a key fob. (Other possibilities are described
`below.) Additionally, a device can include a Software pro
`gram for carrying out the method, for example, as Software
`executing on a general-purpose computer, handheld com
`puter, telephone, personal digital assistant, and So on, or in
`
`IPR2018-00067
`Unified EX1024 Page 11
`
`

`

`US 2004/0172535 A1
`
`Sep. 2, 2004
`
`Some other manner. The device may, in Some implementa
`tions, allow the user to input a Second Secret, Such as a PIN,
`Verifier identifier, and So on, in order to generate an authen
`tication code.
`0.017. In general, in one aspect, the invention relates to an
`authentication device that generates an identity authentica
`tion 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 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.
`0.018. 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 com
`municate the event State.
`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 informa
`tion 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.
`0021. In general, in another aspect, the verifier receives
`authentication information that includes an identity authen
`tication 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 authen
`tication 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.
`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 respec
`tive bit associated with the time period. In such an embodi
`ment, there are two possible States associated with a time
`period, depending on the value of the 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 (asso
`ciated 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 gener
`ating an identity authentication code associated with an
`authentication device includes an authentication code gen
`erator. The authentication code generator generates an iden
`tity authentication code that depends at least in part on a
`dynamic value that changes over time, an event State indica
`tive 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.
`
`IPR2018-00067
`Unified EX1024 Page 12
`
`

`

`US 2004/0172535 A1
`
`Sep. 2, 2004
`
`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.
`
`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.
`0029 FIG. 1 is a block diagram depicting an authenti
`cation 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.
`0.031
`FIG. 3 is a block diagram depicting the generation
`of an authentication code according to an embodiment of the
`invention.
`0.032
`FIG. 4 is a block diagram depicting a detailed
`implementation of the embodiment of FIG. 3.
`0.033
`FIG. 5 is an example demonstrating the use of
`event State data in generating an authentication code.
`0034 FIG. 6 is a flowchart depicting an embodiment of
`a method for generating an authentication code.
`0.035
`FIG. 7 is a block diagram depicting the generation
`of an authentication code according to an embodiment of the
`invention.
`0.036
`FIG. 8 is a block diagram depicting the generation
`of an authentication code 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” and
`“verify can be used interchangeably throughout. Also,
`although the Specification will 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 com
`puter. 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 authen
`tication 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 embodi
`ment, 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 com
`puter. 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 implementa
`tions 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 com
`bination 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, 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 infor
`mation 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 graph
`ics 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 finger
`print, 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 vari
`ous forms in various embodiments of the invention, pro
`vided 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, the user authentica
`tion device 120 can be a credit-card sized and shaped device,
`
`IPR2018-00067
`Unified EX1024 Page 13
`
`

`

`US 2004/0172535 A1
`
`Sep. 2, 2004
`
`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 authen
`tication information requests, or for other entry or interac
`tion 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 com
`municates 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 progr