United States Patent (19)
`Guthrie et al.
`
`54 PERSONAL AUTHENTICATION SYSTEM
`AND METHOD FOR MULTIPLE COMPUTER
`PLATFORM
`
`(75) Inventors: R. Scott Guthrie; Charles E. Waid,
`Jr., both of Colorado Springs, Colo.
`73 Assignee: MCI Communications Corporation,
`Washington, D.C.
`
`21 Appl. No.: 09/036,290
`1-1.
`22 Filed:
`Mar. 6, 1998
`(51) Int. Cl." ...................................................... G06F 17/30
`52 U.S. Cl. ................................ 713/201: 707/2; 709/229
`58) Field of Search
`s 713201 200
`- - - - - - - - - - - -707/2,204,380f48: 709226
`s
`s
`s
`References Cited
`
`56)
`
`U.S. PATENT DOCUMENTS
`364/401
`5,557.515 9/1996 Abbruzzese et all
`5594,227 1/1997 Deo. ... 235/380
`5,751,812 5/1998 Anderson .................................. 380/48
`
`USOO6161185A
`Patent Number:
`11
`(45) Date of Patent:
`
`6,161,185
`Dec. 12, 2000
`
`5,757,916 5/1998 MacDoran et al. ....................... 380/25
`5,864,676
`1/1999 Beer et al. ..........
`... 395/200.59
`5,884,298 3/1999 Smith, II et al. ........................... 707/2
`5,935,246 8/1999 Benson ...........
`... 713/200
`6,000,033 12/1999 Kelley et al. ........................... 713/201
`
`Primary Examiner Albert De Cady
`ASSistant Examiner-Omar Omar
`57
`ABSTRACT
`
`A personal authentication System provides at least two levels
`of Security for an authentication process, in addition to
`numerous other Security features. The System operates
`across many different Software and hardware platforms, in a
`client/server fashion, employing a challenge/response pro
`ceSS that does not require users to transmit their passwords
`acroSS a network. An application running on a client com
`puter is coupled with an application running on a Server
`computer. The client generates a response to a challenge,
`which is provided by the server. The response is a combined
`function of the Server's challenge, a Serial number assigned
`to the client, and a password provided by the user.
`
`27 Claims, 17 Drawing Sheets
`
`122 Client SADB
`
`
`
`SADB
`
`Password 7
`
`Challenge
`
`
`
`
`
`
`
`
`
`Dial-in Access
`Client
`Application
`
`Dial-in ACCess
`Server
`Application
`
`al
`
`Server SADB
`
`m m m m. m. m. m. m. m.
`
`
`
`
`
`
`
`
`
`Challenge
`Generator
`
`BANK OF AMERICA ET AL. EXHIBIT 1007
`
`Page 1 of 29
`
`

`

`U.S. Patent
`
`Dec. 12, 2000
`
`Sheet 1 of 17
`
`6,161,185
`
`
`
`
`
`
`
`1OO
`
`106
`
`
`
`Internal
`NetWork
`
`NetWork
`Resources
`
`FIG. 1B
`
`Page 2 of 29
`
`

`

`U.S. Patent
`U.S. Patent
`
`Dec. 12, 2000
`
`Sheet 2 of 17
`
`6,161,185
`6,161,185
`
`vol
`
`cOlk
`
`
`
`8dvsJeMes
`
`davswallD
`
`
`
`
`
`
`
`
`
`
`
`Page 3 of 29
`
`
`
`ss9ooyUI-|eIGsseooyUI-|BIG
`
`
`
`
`
`
`
`JOAIBSwUal|D
`
`
`
`uoneojddyuoneolddy
`
`6Old
`
`Page 3 of 29
`
`
`
`

`

`U.S. Patent
`
`Dec. 12, 2000
`
`Sheet 3 of 17
`
`6,161,185
`
`
`
`1 10, 116
`
`Serial
`Number
`
`SADB
`
`Challenge
`
`FIG. 3
`
`Page 4 of 29
`
`

`

`U.S. Patent
`U.S. Patent
`
`Dec. 12, 2000
`Dec. 12, 2000
`
`Sheet 4 of 17
`Sheet 4 of 17
`
`6,161,185
`6,161,185
`
`POL
`
`cl
`
`bik
`
`
`
`piomssed/‘p'|JuNoooRWasn:Z
`
`
`
`aBusyjeud:¢
`
`
`
`asuodsal:G
`
`
`
`payle}JOpepasoonsUoHeoUayINe:g
`
`OUJeI|YIOMION——
`
`WUa!|D
`
`
`
`piomssed/‘plJunoooeJasn=}
`piomssedgqys‘7(=n)
`
`
`
`
`
`UONOeIA}UyJES/)
`
`b‘SIs
`
`
`
`
`
`Page 5 of 29
`
`Page 5 of 29
`
`
`
`
`

`

`
`
`
`
`wallDd||yunosoyPJOMSSEdSSO00YUl-|eIGSSoo0yUl-|BIq
`
`
`sajqelJ8N9S
`[BUas
`vel
`
`efuayeu9|Peas
`
`
`
`
`
`
`
`
`
`
`
`
`
`uoneoddyuoyeoddy
`
`gdavs
`
`Dec. 12, 2000
`Dec. 12, 2000
`
`Sheet 5 of 17
`Sheet 5 of 17
`
`6,161,185
`6,161,185
`
`19s)\gavsLa|ozs
`
`JOquUINN
`
`ebueyeuy
`
`U.S. Patent
`U.S. Patent
`
`
`
`Page 6 of 29
`
`Page 6 of 29
`
`
`
`

`

`U.S. Patent
`
`Dec. 12, 2000
`
`Sheet 6 of 17
`
`6,161,185
`
`
`
`User ACCOUnt D
`
`Serial Number
`
`Failures Value
`
`Number of AllOWances
`
`2OO
`
`LOCk-Out Timer
`
`Response
`Response Timer
`ACCOunt Duration
`
`SADB PaSSWOrd
`
`2O2
`
`122
`
`2O8
`
`21 O
`
`212
`
`214
`
`216
`
`218
`
`124
`
`FIG. 6
`
`Page 7 of 29
`
`

`

`U.S. Patent
`
`Dec. 12, 2000
`
`Sheet 7 of 17
`
`6,161,185
`
`Authentication Server Side Processing
`User (Client) Side Processing
`-H
`--
`6O2
`User Initiates Authentication supplying
`ACCount D/Name and
`SysAdmin Request Flag
`
`6O4
`Client requests SADB Challenge
`from Server
`
`608
`
`6O6
`Retrieve ACCOUnt information
`from database for account
`name provided.
`
`YeS
`
`NO
`
`USer is told 'Bad PaSSWOrd'. STOP
`
`Return Failure to Client
`
`61O
`NO
`
`
`
`ls Lock-Out
`Timer Set and
`Not Expired?
`
`
`
`
`
`614
`
`User is informed to try later. STOP
`
`Yes
`
`612
`
`Return 'TOO Manv Bad
`y
`Passwords. Try Later
`to Client
`
`FIG. 7A
`
`Page 8 of 29
`
`

`

`U.S. Patent
`
`Dec. 12, 2000
`
`Sheet 8 of 17
`
`6,161,185
`
`62O
`User is informed the account
`a
`has expired and to
`contact the SysAdmin. STOP
`
`618
`
`Return "Account has expired.
`a
`Contact SysAdmin' to Client
`
`626
`User is informed the account
`will expire and to contact
`the SysAdmin. CONTINUE
`
`
`
`
`
`
`
`622
`Wi
`Account Expire
`Within X
`Days?
`
`Return "Account will expire in
`'n' days. Contact SysAdmin'.
`
`
`
`
`
`
`
`
`
`628
`Did
`password expire
`With no 'Allowances
`left?
`
`
`
`NO
`
`632
`User is informed the password
`has expired and to contact
`the SysAdmin. STOP
`
`Yes
`
`63O
`
`Return "Password has expired.
`Contact SysAdmin' to Client
`
`
`
`
`
`
`
`634
`
`
`
`Did
`password expire
`With "AllOWances
`left?
`
`
`
`NO
`
`FIG. 7B
`
`Page 9 of 29
`
`

`

`U.S. Patent
`
`Dec. 12, 2000
`
`Sheet 9 of 17
`
`6,161,185
`
`640
`User is informed to Change
`PaSSWOrd.
`CONTINUE
`
`636
`
`decrement available allowances'.
`638
`Return "Password has expired.
`Please change it'.
`
`646
`User is informed to Change
`PaSSWOrd.
`CONTINUE
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`642
`Wi
`Password Expire
`Within N
`Days
`
`Return "Password Will
`expire in N days.
`Please Change it'.
`
`648
`
`NO
`
`ls request
`for a SysAdmin
`Authentication?
`
`Yes
`
`GD)
`
`
`
`650
`
`ls
`SysAdmin
`indicator in SADB
`reCOrds O2
`
`
`
`Yes
`
`654
`User is informed the account
`Authentication ACCeSS. STOP
`
`NO
`
`652
`
`Return "Not a
`SysAdmin Account
`
`FIG. 7C
`
`Page 10 of 29
`
`

`

`U.S. Patent
`
`Dec. 12, 2000
`
`Sheet 10 Of 17
`
`6,161,185
`
`656
`
`Generate 8 digit
`Challenge Value
`
`658
`Calculate the Expected
`Response Value and
`place it in the Database
`Record to be Written.
`
`
`
`66O
`Set 2 minute Response Valid
`Timer value in Database
`ReCOrd to be Written.
`
`662
`Update Database Record with
`new values.
`
`
`
`
`
`664
`Error updatingNNo
`SADB Record?
`
`668
`
`Yes
`
`666
`
`User is asked to try
`again later.
`STOP
`
`Return 'Internal SADB Error";
`Report error to administrator.
`
`
`
`672
`The Challenge Value is used
`With the Client Calculator
`to Determine the
`Response Value.
`
`670
`
`Return 8 Digit
`Challenge Value.
`STOP
`
`FIG. 7D
`
`Page 11 of 29
`
`

`

`U.S. Patent
`
`Dec. 12, 2000
`
`Sheet 11 Of 17
`
`6,161,185
`
`Authentication Server Side Processing
`User (Client) Side Processing
`-T-
`8O2
`User calculates SADB Response using
`the SADB Calculator Client Program.
`804
`User sends SADB ACCOUnt Name and
`calculated response to the SADB
`Server for authentication.
`
`8 O6
`
`and Response from Client.
`8O8
`Retrieve ACCOunt information
`from SADB database for
`account name provided.
`
`<G>e
`
`NO
`
`
`81 O
`Return Failure to Client.
`
`
`
`814
`
`
`
`
`
`ls
`Lock-Out Timer
`Set and Not
`Expired?
`
`NO
`
`316
`Yes
`Return Failure to Client.
`
`812
`
`User is told Althcation Failure."
`
`818
`User is told Agreation Failure."
`
`FIG. 8A
`
`Page 12 of 29
`
`

`

`U.S. Patent
`
`Dec. 12, 2000
`
`Sheet 12 Of 17
`
`6,161,185
`
`824
`User is told Aghsation Failure.
`
`
`
`
`
`
`
`HaS
`Response
`Valid Timer
`Expired?
`
`82O
`
`NO
`
`Yes
`
`822
`Return Failure to Client.
`
`
`
`826
`ls Responsen Yes
`Received
`Correct?
`NO
`
`GE)
`
`828
`
`Failures.
`
`830
`
`Have We
`reached Maximumnyes
`Failures
`AllOWed?
`
`
`
`
`
`
`
`
`
`
`
`834
`
`User is told Algication Failure.
`
`NO
`
`83
`2
`Return Failure to Client.
`
`84O
`
`User is told Algiscation Failure."
`
`|
`
`
`836 3
`Set LOCk-Out Timer
`8 3 8
`
`Return Failure to Client
`
`ad
`
`FIG. 8B
`
`Page 13 of 29
`
`

`

`U.S. Patent
`
`Dec. 12, 2000
`
`Sheet 13 Of 17
`
`6,161,185
`
`842
`Reset Log-On Failures to Zero.
`
`844
`Yes SysAdmin flag
`
`
`
`
`
`Set Response
`Expiration to
`SysAdmin Delay.
`
`
`
`Set Response
`Expiration
`to Zero.
`
`848
`Clear Response
`Value
`
`850
`Write (update) SADB
`Database Record.
`
`852
`
`<G>e
`
`NO
`
`854
`
`Report Error.
`
`858
`
`Client Application receives
`"Success Authentication' Message.
`
`856
`Return 'SuCCess' to Client.
`STOP
`
`FIG. 8C
`
`Page 14 of 29
`
`

`

`U.S. Patent
`
`Dec. 12, 2000
`
`Sheet 14 of 17
`
`6,161,185
`
`900
`X
`SADB Calculator 3.0 SN: LD4ZS43W
`Enter Challenge:
`<Clipboard
`
`
`
`
`
`912
`
`
`
`
`
`SADB Response:
`Property of MC
`
`906
`908
`914
`910
`
`904
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`926
`
`SADB 3.0 initialization
`Enter the 8 character SADB 3.0 serial number you
`received during registration for your dial-in account. 922
`
`You MUST enter the serial number you were
`assigned: SADB 3.0 Calculators with other
`serial numbers will not work with your account.
`If you have re-named the SADB 3.0 calculator
`executable, change its name to match below:
`SADB 3OC.EXE
`
`Set Serial Number
`
`Enter Serial Number & Press 'Set Serial Number
`
`920
`
`924
`
`928
`
`FIG. 9B
`
`Page 15 of 29
`
`

`

`U.S. Patent
`
`Dec. 12, 2000
`
`Sheet 15 0f 17
`
`6,161,185
`
`104
`
`Server SADB
`
`
`
`
`
`FIG. 10
`
`Page 16 of 29
`
`

`

`U.S. Patent
`
`Dec. 12, 2000
`
`Sheet 16 0f 17
`
`6,161,185
`
`
`
`152
`
`MOdem POO
`1
`
`104
`
`150
`
`
`
`f OO
`
`15O'
`
`Modern POO
`2
`
`
`
`Modem POO
`3
`
`152"
`
`104"
`
`FIG. 11A
`
`Page 17 of 29
`
`

`

`U.S. Patent
`
`Dec. 12, 2000
`
`Sheet 17 Of 17
`
`6,161,185
`
`
`
`150
`
`104
`
`
`
`
`
`1 O2
`
`a
`
`104
`
`
`
`
`
`MOClem POO /N
`
`3
`
`FIG. 11B
`
`
`
`104
`
`FIG. 12
`
`Page 18 of 29
`
`

`

`1
`PERSONAL AUTHENTICATION SYSTEM
`AND METHOD FOR MULTIPLE COMPUTER
`PLATFORM
`
`TECHNICAL FIELD
`The present invention relates generally to electronic
`access Systems and more particularly to electronic acceSS
`Systems in computers.
`
`BACKGROUND OF THE INVENTION
`Access to confidential and proprietary areas are often
`performed using electronic access Systems. Electronic
`access Systems are typically required to acceSS a network,
`network resources (e.g., servers, modems, etc.), Software
`applications running on servers, Internet or World Wide Web
`pages, databases, files or other electronic data. Electronic
`access Systems are particularly important with individual or
`networked computers that Store confidential information.
`Other electronic authorization systems have been devel
`oped to authenticate human users, generally with the use of
`personal passwords. However, these electronic acceSS SyS
`tems provide only a limited level of Security Since they rely
`on authenticating a user account identifier and password,
`thereby providing only one level of Such Security. An
`unauthorized user may obtain an authorized user's password
`and account identifier and thereby inappropriately access the
`System.
`An ideal electronic access System performs user
`authentication, rather than Simply machine or System
`authentication. In other words, Such an electronic acceSS
`System authenticates individuals or users who may acceSS
`the System, rather than a System that has been pre
`programmed with access information (e.g., running a
`"Script to permit access). Such an electronic authorization
`System, to maintain Security, must ensure that only autho
`rized users are allowed access to the System.
`Certain personal authentication Systems are available,
`Such as fingerprint identifiers, retinal Scan devices, etc. Such
`personal authentication Systems, however, are typically very
`expensive and inapplicable to many environments. For
`example, Such fingerprint or retinal Scan identification
`devices are difficult or expensive to employ in a large
`network of computers, including a network where users may
`access the network from various geographic locations (e.g.,
`Via Standard phone lines using a modem and lap top
`computer).
`A lower cost System employs Secure identification (ID)
`cards within a personal authentication System. Such a per
`Sonal authentication System requires use of a physical card
`having an algorithm which generates a random code at
`predetermined intervals (e.g., every 10 Seconds). A server
`computer (or "server') employs the same algorithm to
`generate the Same code at the same predetermined interval.
`Aspects of the generated code are unique to the card. Thus,
`a user must possess the card to obtain authentication by the
`Server. However, if the card is lost or damaged, the user
`cannot be authenticated. Additionally, unauthorized users
`could simply obtain the card and thereby gain access to the
`System. Furthermore, the card requires a battery to energize
`its internal circuitry. Therefore, the card has a limited life,
`after which time a new battery must be inserted.
`Another personal authentication System employs a Soft
`ware solution known as “Softkey.” The Softkey system
`provides a challenge to a user provided by a server, to which
`the user must respond, typically by means of a client
`
`1O
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6,161,185
`
`2
`computer (or “client') coupled to the server. When a user
`initially logs into the Server, the Server, for example, Selects
`eight words from a table of words, where each word has four
`to eight characters. The user must then type in each of the
`eight words. As a result, the user must type 24 to 64
`characters in a response to the Server's challenge. The Server
`generates the same eight words, and compares the eight
`words it receives from the client to those locally generated.
`If the two match, then the user is authenticated.
`One problem with the Softkey system is that the user must
`correctly enter the eight words, requiring up to 64 key
`Strokes. Such a response by the user can be time consuming
`and tedious for non-touch typists. Additionally, the Softkey
`system suffers from additional limitations which make it not
`Sufficiently robust for use in protecting highly confidential
`information on a computer network or in other Suitable
`environments.
`SUMMARY OF THE INVENTION
`An exemplary embodiment of the present invention pro
`vides numerous Security and utility features. Alternate
`embodiments need not include all Such features, and may
`include as few as one of Such features. In contrast to the
`Softkey System, the exemplary embodiment provides a user
`interface that is easy to use without Sacrificing Security.
`Users employ a password that does not change each time a
`user authenticates with a server. As a result, users can
`remember their passwords more easily. The exemplary
`embodiment automatically locks out a user for a time out
`period where the user has attempted authentication for a
`predetermined number of Successive attempts and failed. AS
`the number of authentication failures increases, the time out
`period increases.
`User passwords expire after a predetermined period of
`time, thereby requiring users to change their passwords. The
`exemplary embodiment provides users with Sufficient notice
`before their passwords expire. For users who do not fre
`quently access the System, a predetermined number of
`System accesses are permitted before being locked out from
`the System after the password time period has expired,
`during which users can change their password.
`User accounts in the exemplary embodiment may be set
`to automatically expire at predetermined times without
`direct intervention by a System administrator, to thereby
`provide Specialized accounts for certain users. Again, Such
`users are provided with sufficient notice before their
`accounts expire.
`Under the exemplary embodiment, the Server accepts only
`a single one-time password value which expires within a
`short period of time to thereby foil a malicious user's
`attempt at “hammering the authentication System with
`responses attempting to Stumble upon a correct password
`and gain access.
`Additionally, the exemplary embodiment employs a
`robust encryption or Security algorithm, which is maintained
`in Secrecy by the Server.
`Each client is provided with a separate calculator that is
`customized for the user. The client calculator is sufficiently
`generic So that it can be easily portable to various computer
`Systems. The client calculator is also readily available and
`provided to a wide variety of users. Additionally, the client
`calculator, as well as a corresponding calculator on the
`Server, are not compute intensive. Instead, the central pro
`cessing unit (CPU) and input/output (I/O) processing
`requirements for the calculators are minimal under the
`exemplary embodiment So that authentication can be calcu
`lated in Substantially less than one Second.
`
`Page 19 of 29
`
`

`

`3
`Passwords are Stored on the Server in an encrypted
`manner within internal System tables. As a result, an unau
`thorized user cannot simply observe the raw data to obtain
`uSable information. Each account for a given user has an
`asSociated account type value. As a result, user accounts are
`thereby distinguishable and may have varying levels of
`Security, access, size, etc. The exemplary embodiment
`employs multiple Servers. Each Server automatically updates
`a given change made by another Server (e.g., database
`mirroring). Furthermore, data transmitted over the network
`from one Server to another is not sent as clear text, but is
`instead, for example, encrypted.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`FIGS. 1a and 1b are block diagrams showing two envi
`ronments for incorporating an exemplary embodiment of the
`present invention.
`FIG. 2 is a logical block diagram of a client and a Server
`employing aspects of the exemplary embodiment.
`FIG. 3 is a block diagram illustrating a logical proceSS
`performed by the exemplary embodiment.
`FIG. 4 is a block diagram showing data flows in the
`exemplary embodiment.
`FIG. 5 is a logical block diagram showing a personal
`authentication process under the exemplary embodiment.
`FIG. 6 is a Schematic diagram of an exemplary user
`account table Stored in a user account database, which forms
`part of the server of FIG. 2.
`FIGS. 7a, 7b, 7c and 7d together form a flowchart
`diagram showing a first half of a personal authentication
`proceSS under the exemplary embodiment.
`FIGS. 8a, 8b and 8c together form a flowchart diagram
`showing a Second path of the personal authentication pro
`ceSS under the exemplary embodiment.
`FIG. 9a is a front view of a computer screen showing a
`window for a client calculator.
`FIG. 9b is a front view of a computer screen showing a
`window for initializing the client calculator.
`FIG. 10 is a block diagram showing a first alternate
`embodiment of the present invention.
`FIG. 11a is a block diagram showing a Second alternate
`embodiment of the present invention.
`FIG. 11b is a logical block diagram for the embodiment
`of FIG. 11a.
`FIG. 12 is a block diagram showing a third alternate
`embodiment of the present invention.
`DETAILED DESCRIPTION OF THE
`INVENTION
`An electronic access System, and in particular, a method
`and apparatus for authenticating users of a computer, is
`described in detail herein. In the following description,
`numerous Specific details, Such as Security algorithms,
`ordering and execution of Steps, hardware components, etc.,
`are presented in order to provide a thorough understanding
`of the present invention. One skilled in the relevant art,
`however, will readily recognize that the invention can be
`practiced without using the Specific details described herein,
`or with other specific Steps in a routine, different Security
`algorithms, different hardware, etc. Well-known structures
`and StepS are not shown or described in detail in order to
`avoid obscuring the present invention.
`AS explained herein, an exemplary embodiment of the
`present invention provides a personal authentication System
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6,161,185
`
`4
`that may be combined with a System's conventional authen
`tication procedures to provide at least two levels of Security,
`in addition to other Security features. A conventional first
`level of Security requires, e.g., a user to provide an account
`identifier and corresponding account password to initially
`log on to or access the Server. Thereafter, the exemplary
`embodiment provides a Second level of Security under a
`challenge/response process. The personal authentication
`System can operate acroSS many different Software and
`hardware platforms in a client/server fashion, and is based
`on a challenge/response process that does not require users
`to transmit certain important authentication information
`acroSS the network.
`The exemplary embodiment is embodied in an application
`running on a client computer coupled with an application
`running on a Server computer. The applications both include
`a "calculator' which generates a unique response based on
`a Seed value. The Server provides an initial Seed value or
`“challenge' during each request for access. The client
`employs the challenge, together with a unique Serial number
`assigned to the client's calculator and an authentication
`password provided by the user, to generate a response. The
`Server calculator Similarly generates a response. The client
`transmits its generated response to the Server which com
`pares the received response to the locally generated response
`to authenticate the user. As a result, the user's authentication
`password is never transmitted over the network where it
`could be exposed or compromised.
`The exemplary embodiment provides Several additional
`Security features. The Server's calculator locks out a user and
`denies access after a certain number of failed attempts and
`denies access for a certain period of time. The time period
`increases for each Series of failed attempts, thereby prevent
`ing an unauthorized user from using a random code genera
`tor to generate a correct response value. Account passwords
`expire after a selected period of time (typically measured in
`weeks) and the response generated by the client's calculator
`is invalid (even if correct) after a short period of time
`(typically measured in minutes). The client and Server
`calculators employ a Secured, one-way hashing algorithm
`which is difficult, if not impossible to reverse compute. The
`hashing algorithm employs a unique Serial number assigned
`to the client's calculator to thereby customize each client's
`calculator. A user can have multiple copies of the client
`calculator (e.g., on home, office, portable, etc. computers),
`where each copy contains the same Serial number. Thus, the
`Serial number together with the user's password provide
`authentication of the user. The exemplary embodiment also
`provides other important features described herein.
`Referring to FIG. 1a, a network 100 has coupled thereto
`a client 102 and a server 104. The server 104 may be
`implemented on a high-grade, mid-range computer, Such as
`the IBM RS/6000 from International Business Machines
`Corporation, a DEC alpha-based computer from Digital
`Equipment Corporation, or Windows NT systems.
`Alternately, the server 104 may be a much smaller computer
`such as a DOS-based personal computer (PC). A software
`routine running on the client 102, together with a similar
`Software routine running on the Server 104, authenticate a
`user of the client, as explained more thoroughly below. An
`exemplary embodiment of the present invention authenti
`cates a user of the client 102 to permit the user access to the
`Server 104, as well as access to any resources on the Server,
`Such as Software applications, files and databases.
`Messages and other data are exchanged between the client
`102 and the server 104 via the network 100. The network
`100 may be a public Switched telephone network (PSTN),
`
`Page 20 of 29
`
`

`

`25
`
`S
`Such as in a dial-in or other access configuration. Alternately,
`the network 100 may be a transmission control protocol/
`internet protocol (TCP/IP) based network, such as the Inter
`net or a corporate intranet. The network 100 may also be a
`private line network, local area network, or any other
`network for exchanging messages.
`Referring to FIG. 1b, an alternative System incorporating
`an exemplary embodiment of the present invention includes
`an internal network 106 coupled to the server 104. The
`internal network 106 may be a corporate internal network,
`Such as a corporate intranet. Additionally, network resources
`108 are coupled to the server 104. Network resources may
`include modems, other Servers, printers, and other hardware,
`or Software resources to which the client 102 desires access
`(via the server).
`Referring to FIG. 2, the client 102 includes a client Secure
`Authentication DataBase (SADB) calculator 110 and a client
`application 112 with which a human user 114 interacts. In
`the exemplary embodiment, the client SADB calculator 110
`is a Software-based authorization facility; however, a hard
`ware based calculator may be employed, Such as a card or
`chip to be coupled to the client 102. The client application
`112 provides a conventional communication with the Server
`104 over the network 100 (e.g., dial-up connection over the
`PSTN). If the network 100 is the Internet or other TCP/IP
`network, then the client application 112 is a TCP/IP interface
`and web browser for internet access to the server 104.
`The client SADB calculator 110 provides a second level
`of authentication for the user 114 under a challenge/response
`routine, as described below. The server 104 similarly
`includes a server SADB calculator 116, and a server appli
`cation 118, e.g., a dial-in application. Instead of dial-in
`access applications, the applications 112 and 118 may be
`other methods and/or apparatuses for establishing commu
`nications between the client 102 and server 104. The server
`35
`104 also includes a user account database 120 which
`includes tables of user accounts, including account IDS. The
`Server 104 may also include a database having account
`passwords with asSociated account ID'S to provide a first
`level of authentication, in a manner Similar to that found in
`conventional password protected Systems, but with addi
`tional functionality.
`The user 114 must initially establish an account with the
`server 104, which is stored in the user account database 120.
`For example, the user 114 initially establishes an account
`with the server 104. The user 114 receives a user account ID
`and receives (or provides) an account password.
`After establishing an account, the user 114 receives a copy
`of the client SADB calculator 110. The user 114 can obtain
`the client SADB calculator 110 by known software distri
`bution methods, Such as by downloading a copy of the
`SADB calculator from the server 104, or by accessing a web
`page over the Internet which permits a copy to be down
`loaded. The user 114 also receives a unique Serial number for
`use with the client SADB calculator 110, Such as from an
`55
`account administrator. The user 114 thus has a SADB
`account and a corresponding user account ID. Typically, the
`user's account, and the user's SADB account differ,
`although Such accounts could be Stored together and be
`assigned the same user account ID.
`The user 114 installs the client SADB calculator 110 on
`the client 102. During such installation, the client SADB
`calculator 110 prompts the user 114 to enter the serial
`number. The serial number is then stored internally in the
`client SADB calculator 110 as explained herein, and thus
`does not need to be memorized by the user 114 or input
`thereafter.
`
`45
`
`50
`
`60
`
`65
`
`6,161,185
`
`15
`
`40
`
`6
`The user 114 may use more than one client computer 102
`to access the server 104 (e.g., via a home computer, office
`computer, lap top computer, palm top computer, etc.). If So,
`then the user 114 installs a copy of the client SADB
`calculator 110 on each of Such client computers and inputs
`the same Serial number to each calculator. The user 114 can
`then access the server 104 and be authenticated with the
`Same account ID, passwords, etc., no matter which client
`computer the user employS.
`Referring to FIG. 3, a Simplified logical diagram of a
`process performed by the client and server SADB calcula
`tors 110 and 116 is shown. Initial data or vectors include a
`Serial number 122 previously input by the user (as discussed
`above). Additional initial data includes a user's authentica
`tion or SADB password 124 and challenge data 126
`(described below), which are input together with the serial
`number 122 to a secured hashing algorithm (SHA) 128. As
`is known, a SHA is a one-way hashing algorithm which
`generally cannot be reverse computed. Therefore, the input
`to the SHA128 (e.g., the SADB password 124) cannot be
`determined from the output. By employing the Serial number
`122, SADB password 124 and challenge 126, the SHA128
`generates a unique response 130. The SHA 128 can be
`configured to provide a desired format and length response
`130, such as a five or six character response. A response 130
`which includes too many characters can be difficult for the
`user to employ.
`In the exemplary embodiment, the serial number 122
`employs only numeric and capital alphabetic characters, and
`the letters “O,” “I” and “L” as well as the numbers “1” and
`“0, are prohibited to eliminate potentially confusing (as
`look-alike) letters and numbers. Additionally, the Serial
`number does not include any vowels. Therefore each char
`acter in the serial number 122 can have only one of 28
`values. As a result, if the serial numbers distributed to the
`users are randomly generated, profane or other inappropriate
`words are not accidentally created. The serial number 122
`need not be a unique value. The SHA128 similarly avoids
`the letters “O'”, “L”, “I”, the digits “0” and “1”, and vowels
`when generating the response 130.
`The SADB password 124 may be automatically generated
`by the server 104, but may later be altered by the user. The
`system preferably requires that the SADB password 124
`Satisfy one or more of the following based on the Security
`policy in effect: a minimum length in characters, a required
`mix of characters (e.g., requiring at least Some number of
`characters from Some number of the groups of upper case,
`lower case, numerics, special characters); non-reuse of pre
`viously used passwords, etc. The SADB password 124 is the
`user's "Secret” which expires and must be changed. Typical
`lifetimes for the user's authentication password range from
`a week to Several months, depending upon Security policy
`requirements for the system. Since the SADB password is
`provided by the user during authentication, users often wish
`to personalize their passwords.
`Conversely, the challenge 126 is generated by the Server
`104 and provided to the client 102. The challenge is pref
`erably randomly generated. For example, the challenge may
`be a String of eight alphanumeric characters or digits. The
`eight digit challenge value 126 provided by the server 104
`is used to create a different response value 130 for each
`authentication attempt made within the time-frame that the
`user's SADB password 124 remains unchanged.
`The serial number 122 and SADB password 124 are
`Stored in the user's account table in the user account
`database 120. Using the same serial number 122, SADB
`
`Page 21 of 29
`
`

`

`7
`password 124 and challenge 126, both the client and server
`SADB calculators 110 and 116 should produce the same
`response 130. Therefore, the client and server SADB cal
`culators 110 and 116 have the same input values to the SHA
`128. The client 102 then transmits the response 130 pro
`duced by the client SADB calculator 110 to the server 104.
`The Server 104 compares its internally generated response
`130 with the response received by the client 102 to authen
`ticate the user 114, as explained herein.
`Referring to FIG. 4, six consecutive paths or flow of data
`under the exemplary embodiment are shown as enumerated
`as paths “1” through “6.” As shown in FIG. 5, a logical
`representation of the authentication process under the exem
`plary embodiment is shown. Referring to FIGS. 4 and 5, if
`the System employs a conventional first level of
`authentication, then the user 114 initially inputs the user's
`account and correct password to the client 102. Secondly, the
`client 102, via the client application 112, transmits the user
`account and account password to the server 104. Third, the
`Server 104 validates the user account and password against
`the user's account table Stored in the user account database
`120. If Such initial validation is successful, then the server
`104 employs a challenge generator 134 in its SADB calcu
`lator 116 to