USOO8751801 B2
`
`(12) United States Patent
`Harris et al.
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 8,751,801 B2
`Jun. 10, 2014
`
`(54)
`
`(75)
`
`(73)
`
`(*)
`
`(21)
`(22)
`(65)
`
`(63)
`
`(60)
`
`(51)
`
`(52)
`
`SYSTEMAND METHOD FOR
`AUTHENTICATING USERSUSING TWO OR
`MORE FACTORS
`
`Inventors: William H. Harris, Woodside, CA (US);
`Louis A Gasparini, San Mateo, CA
`(US)
`Assignee: EMC Corporation, Hopkinton, WA
`(US)
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 2368 days.
`Appl. No.: 11/112,938
`Filed:
`Apr. 22, 2005
`
`Notice:
`
`Prior Publication Data
`US 2005/02681 07 A1
`Dec. 1, 2005
`
`Related U.S. Application Data
`Continuation-in-part of application No. 11/050,549,
`filed on Feb. 3, 2005, now Pat. No. 7,730,321, and a
`continuation-in-part of application No. 10/435,322,
`filed on May 9, 2003, now Pat. No. 7,100,049.
`Provisional application No. 60/565,057, filed on Apr.
`23, 2004, provisional application No. 60/565,692,
`filed on Apr. 26, 2004.
`
`(2006.01)
`(2006.01)
`(2013.01)
`(2013.01)
`(2013.01)
`(2012.01)
`(2012.01)
`
`Int. C.
`H04L 9M32
`H04L 29/06
`G06F 2/3
`G06F2L/42
`G06F2L/35
`G06O20/40
`G06O20/12
`U.S. C.
`CPC ............ G06F 2 1/35 (2013.01); H04L 63/0861
`(2013.01); G06F 21/31 (2013.01); G06F 2 1/42
`(2013.01); G06O20/40145 (2013.01); H04L
`
`9/3231 (2013.01); H04L 63/083 (2013.01);
`G06O20/12 (2013.01); H04L 63/0853
`(2013.01); H04L 63/18 (2013.01)
`USPC ............................................... 713/168; 726/7
`(58) Field of Classification Search
`USPC ........................... 713/186, 201, 176; 382/125
`See application file for complete search history.
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`5,953,700 A *
`6,161,139 A
`
`9/1999 Kanevsky et al. ......... TO4/270.1
`12/2000 Win et al.
`(Continued)
`
`FOREIGN PATENT DOCUMENTS
`
`EP
`WO
`WO
`
`O476O929
`O118636
`O163878
`
`4/2007
`3, 2001
`8, 2001
`
`OTHER PUBLICATIONS
`Looi, M. ; Enhanced authentication services for Internet systems
`using mobilenetworks; Publication Date: 2001 vol. 6, on pp. 3468
`3472 vol. 6.
`(Continued)
`Primary Examiner — Philip Chea
`Assistant Examiner — Monjour Rahim
`(74) Attorney, Agent, or Firm — Ryan, Mason & Lewis, LLP
`
`ABSTRACT
`(57)
`A method for authenticating a user based on a plurality of
`authentication factors includes a step of receiving a first
`authentication factor from a first communication device of the
`user. The first authentication factor includes a password. The
`method includes a step of receiving a second authentication
`factor. The second authentication factor comprises at least
`one of at least one device identifier of the first communication
`device of the user and data transmitted to or received from a
`second communication device of the user. The method also
`includes a step of authenticating the user based on at least the
`received plurality of authentication factors.
`20 Claims, 6 Drawing Sheets
`
`3rd FACTOR
`
`BIOM
`
`st
`
`WOICE
`ISSUE CHALLENGE
`PHRASE, RECRESP
`612
`COMPARE WOICE TO
`REGO WOICEPRN
`
`
`
`3rd NO
`
`f
`
`C
`THRFACTOR AUTHEN
`TCATON PASSE
`
`sts
`
`IPR2018-00067
`Unified EX1013 Page 1
`
`

`

`US 8,751,801 B2
`Page 2
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`6,389,542 B1
`6,401,125 B1
`6,632,248 B1
`7,353,396 B2*
`7,426,750 B2 *
`7,480,915 B2*
`2003/0051147 A1*
`2003,019 1949 A1*
`
`5, 2002
`6, 2002
`10, 2003
`4, 2008
`9, 2008
`1/2009
`3, 2003
`10, 2003
`
`Flyntz
`Makarios et al.
`Isaac et al.
`Micali et al. .................. 713, 176
`Cooper et al. ........
`... 726/26
`Costa Requena et al. ... 719/311
`Maeda et al.
`... 713, 186
`Odagawa ...................... T13, 186
`
`1/2004 Kocher ......................... 382,125
`2004/0017934 A1
`2005/0050322 A1* 3, 2005 Mizrah .
`... 713,168
`2005, 0071673 A1* 3, 2005 Saito ...............
`T13 201
`2005/02099.74 A1* 9, 2005 OkunSeinde et al. ........... TO5.64
`
`
`
`OTHER PUBLICATIONS
`
`Written Opinion of the International Searching Authority, Oct. 5,
`2006, 3 pages.
`International Search Report, Oct. 5, 2006, 2 pages.
`* cited by examiner
`
`IPR2018-00067
`Unified EX1013 Page 2
`
`

`

`U.S. Patent
`
`Jun. 10, 2014
`
`Sheet 1 of 6
`
`US 8,751,801 B2
`
`150 r
`
`STORAGE
`
`STORAGE
`
`162
`
`172
`
`164
`
`STORAGE
`INPUT
`170
`
`PROCESSOR
`
`
`
`
`
`
`
`176
`
`174
`
`160 O
`
`
`
`
`
`AF/G, 1
`(PRIOR ART)
`
`OUTPUT
`
`168
`
`
`
`A/G 3
`
`FIG. 9 (E)
`
`CALLIESTABLISH COMM
`WITH MOBILE DEVICE
`
`FACT AUTH NEEDED
`
`REG/RCV/COMPARE
`USER ID, PASSWORD
`
`IPR2018-00067
`Unified EX1013 Page 3
`
`

`

`U.S. Patent
`
`Jun. 10, 2014
`
`Sheet 2 of 6
`
`US 8,751,801 B2
`
`SITE TO
`PHONE (TO
`USER) TO
`COMPUTER
`TO SITE
`
`SITE TO
`SITE TO
`COMPUTER PHONE TO
`(TO USER)
`USERTO
`TO PHONE
`PHONE TO
`TO STE
`SITE
`A/G 2
`
`USERTO
`PHONE TO
`SITE
`
`
`
`IPR2018-00067
`Unified EX1013 Page 4
`
`

`

`U.S. Patent
`
`Jun. 10, 2014
`
`Sheet 3 of 6
`
`801 B2
`US 8,751,
`
`DD
`
`W
`
`(E)
`(A) N2
`USER INPUTS SECRET,
`DEVICE (MTS TO SITE
`
`430
`7
`STS RECEIVES DEVICE
`DSECRET
`W
`
`SELECT AUTH METHODI
`XFER METHOD, THRD
`FACTOR METHOD FOR
`SWCSELECTED -- (USR
`A.
`474
`NONE
`DEVOCE
`SECOND FACTOR do
`Rdi
`416
`COMP PC ID WITH
`REGISTERED
`V
`
`
`
`473
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`4.32
`Y
`YES
`pSECRET MATCH d
`VNO
`a
`V
`af
`434 (B)
`(C)
`USER REQUESTS DEVICE
`TO DISPLAY SECRET
`V7
`436
`DEVICE, STE OBTANSI
`GENERATES NEW
`SECRET
`43s
`DR
`DEVOCE DISPLAYS
`SECRET
`V7
`440
`USR RETRWS, PROVIDES
`SECRET FR DEVICE
`442
`PROMPT FOR, OBTAN/
`GENERATE/RECEIVE
`SECRET
`
`
`
`
`
`GENERATED
`SECRET
`
`D-SHARED
`SECRET
`WRFY
`o
`
`
`
`URL ST"C GENERATE
`
`422
`CHG/RESP
`STATIC SECRET
`
`
`
`V
`
`
`
`D
`
`SITE DISPLAYS SECRET,
`ASSOCOATES WITH
`(C)-D
`DEVICE DENTIFIER
`AfG. 4A3
`426
`
`
`
`443
`446
`DISPLAYERROR
`
`O
`
`()
`
`IPR2018-00067
`Unified EX1013 Page 5
`
`

`

`U.S. Patent
`
`Jun. 10, 2014
`
`Sheet 4 of 6
`
`US 8,751,801 B2
`
`(D)
`SITE SENDS, USER RE
`CEIVES SECRET: DEVICE
`
`O
`
`450
`
`USER INPUTS SECRET
`
`462
`
`W
`SITE RECEIVES,
`COMPARES SECRET
`454
`
`
`
`(E)
`USER RECEIVES URL ON
`PHONE
`
`460
`USER INPUTS URL,
`NAVIGATES TO STE
`462
`
`SOE RECEIVES URL
`464
`
`
`
`
`
`NO
`NO
`>C)<
`SECRET ress
`YES Casic acil3 YES
`Y-456 ft/G. 4C
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`WAITIPERFORMADDIT
`IONAL AUTH STEPS
`472
`
`PROVIDE ACCESS TO
`REQUESTED SERVICE
`
`
`
`
`
`
`
`
`
`
`
`STORE/RETRO EVEI
`RECEIVE DEVICE D(S)
`46
`ASSOCATE DEVICEO
`(OPT: VOICE) WITH USER
`40s
`
`
`
`IPR2018-00067
`Unified EX1013 Page 6
`
`

`

`U.S. Patent
`
`Jun. 10, 2014
`
`Sheet 5 of 6
`
`US 8,751,801 B2
`
`VOICE
`
`TONES
`
`
`
`
`
`PROVIDE TEXT TO/
`RECEIVE TEXT FROM
`PHONE WIOUSER INPUT
`(F)
`512
`PROVIDE/RECEIVE TEXT
`
`514
`PROVIDE/RECEIVE
`TONES, DECODE TONES
`516
`
`PROVIDE/RECEIVE VOICE
`
`513
`
`CONVERT TO TEXT
`62O (E
`NO
`OICE 3RD FACTOR
`
`
`
`YES
`COMPARE VOICE TO
`REGD VOICEPRINT
`
`
`
`REQUEST, RECEIVE
`
`620
`OTHER
`BIOM
`
`610
`
`3RD FACTOR
`p
`
`ISSUE CHALLENGE
`PHRASE, RECRESP
`
`an
`612
`COMPARE VOICE TO
`REGD VOICEPRINT
`614
`
`NO
`(C)
`THIRD FACTOR AUTHEN
`TICATION PASSED
`618
`
`A/G. 6
`
`
`
`526
`
`re
`NO (C)
`CONTINUE
`
`A/G. 6
`
`628
`
`IPR2018-00067
`Unified EX1013 Page 7
`
`

`

`U.S. Patent
`
`Jun. 10, 2014
`
`Sheet 6 of 6
`
`US 8,751,801 B2
`
`
`
`COMPUTER
`SYSTEM
`710
`
`MOBILE
`DEVICE
`712
`
`BIOMETRIC
`READER
`714
`
`PC COMM
`INTERFACE
`720
`
`MOBILE
`DEVICE
`INTERFACE
`Z22
`
`REG MANAGER
`730
`
`DATABASE
`732
`
`
`
`RECQUEST
`MANAGER
`740
`
`SECOND
`AUTHENTICTN
`AUTHENTICTR
`760
`
`FIRST
`AUTHENTCTN
`MANAGER
`742
`
`THIRD
`AUTHENTICTN
`MANAGER
`752
`
`BIOMETRIC
`INTERFACE
`Z24
`
`BIOMETRIC
`REGISTRATN
`MANAGER
`734
`
`SUBSEQUENT
`AUTHNTCTN
`IDENTIFIER
`Z44
`
`ADDITIONAL
`AUTHENTCTN
`MANAGER
`754
`
`
`
`
`
`
`
`
`
`BIOMETRIC
`COMPARE
`MANAGER
`766
`
`AUTHENTICATION
`AND SERVICE SYSTEM
`700
`
`SERVICE
`PROVIDER
`760
`
`IPR2018-00067
`Unified EX1013 Page 8
`
`

`

`US 8,751,801 B2
`
`1.
`SYSTEMAND METHOD FOR
`AUTHENTICATING USERSUSING TWO OR
`MORE FACTORS
`
`RELATED APPLICATIONS
`
`This application claims the benefit of U.S. Provisional
`Patent Application Ser. No. 60/565,057 entitled, “Method and
`Apparatus for Authenticating Users Using Two Factors' filed
`by William Harris and Louis Gasparinion Apr. 23, 2004, and
`U.S. Provisional Patent Application Ser. No. 60/565,692
`entitled, “Method and Apparatus for Authenticating Users
`Using Two or More Factors' filed by William Harris and
`Louis Gasparini on Apr. 26, 2004 and is a continuation in part
`of application Ser. No. 11/050,549 entitled, “System and
`Method for Authentication of Users and Communications
`Received from Computer Systems' filed on Feb. 3, 2005 now
`U.S. Pat. No. 7,730,321 by Louis Gasparini and William
`Harris, and application Ser. No. 10/435,322 entitled,
`“Method and Apparatus for Authentication of Users and Web
`Sites' filed on May 9, 2003 now U.S. Pat. No. 7,100,049 by
`Louis Gasparini and Charles Gotlieb, each having the same
`assignee as this application and all are incorporated herein by
`reference in their entirety.
`
`BACKGROUND OF THE INVENTION
`
`Strong user authentication is achieved through the simul
`taneous presentation of multiple authentication factors, clas
`sically defined as: (1) Something you know, (2) Something
`you have, and (3) Somethingyou are. Most e-commerce today
`is based upon weak authentication utilizing only one fac
`tor—a password (something you know). Because of the
`increase of password-stealing exploits on the Internet, wider
`adoption of two-factor authentication is desirable.
`However, two-factor authentication has been difficult to
`deploy, because it traditionally requires either (a) the distri
`bution of new hardware to the user, such as a key fob or a
`smart card and reader, and/or (b) the installation of new soft
`ware on the user's computer, such as a digital certificate.
`Therefore, the use of two-factor authentication has been lim
`ited to a relatively small number of very high-value relation
`ships and transactions.
`Individuals must present credentials to demonstrate that
`they are who they claim to be. These credentials are varied,
`and fall into three types, often referred to as authentication
`factors:
`1. Information (“Something You Know')
`Password, passphrase, PIN. Zip code, phone number,
`Social Security number, account number, mother's maiden
`name, recent transactions, credit history, etc.
`2. Object (“Something You Have')
`Credit card, driver's license, ID card, passport, ticket,
`paper certificate, Smart card, contactless card or key fob,
`dynamic password generator, phone, PDA, computer, periph
`eral, etc.
`3. Person (“Something You Are”)
`There is only one instance of a person, but there are numer
`ous ways to measure a person: photograph, signature, finger
`print, retinal scan, hand geometry, facial geometry, Voice
`print, DNA analysis, etc.
`Because individual credentials can be stolen or counter
`feited, security can be increased by using multiple creden
`tials. Multiple credentials of the same type offer less
`increased security than credentials of different types, because
`they can often be misappropriated at the same time in the
`same way. (For instance, if an attacker steals your wallet, he
`
`10
`
`15
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`will get your driver's license and your credit cards.) But
`because credentials of different types must generally be sto
`len using different types of attack, the simultaneous use of
`different types of credentials—“multi-factor authentica
`tion—increases the strength of an authentication. (For
`instance, an attacker might steal your wallet and get your
`ATM card, but would not have your PIN. Oran attacker might
`surreptitiously observe you entering your PIN, but would not
`have physical possession of your ATM card.)
`In face-to-face interactions, credentials of all three types
`can be directly inspected. However, in remote interactions
`such as those done over the Internet, credentials which are
`objects or persons cannot be directly inspected—so their
`presence and authenticity should be verified in some other
`way. Typically, this is done by accessing some unique data
`stored on the object (such as the data encoded on a magnetic
`card) or by taking some measurement of the object or person
`(such as the fingerprint of a person). To prevent the fraudulent
`replay of Such data, Some systems employ dynamic data or a
`cryptographic challenge-response.
`Systems which utilize objects or persons as authentication
`factors in remote electronic authentication generally require
`one or more of the following: (1) new software installed on
`the user's computer, (2) new hardware—such as a reader—
`attached to the computer, and/or (3) a hardware token, such as
`a smart card or a key fob, distributed to the user.
`What is needed is a system and method that can perform
`two-or-more-factor authentication that can be deployed with
`out requiring any software or hardware that the typical Inter
`net user doesn't already possess.
`
`SUMMARY OF INVENTION
`
`A method for authenticating a user based on multiple
`authentication factors includes a step of receiving a first
`authentication factor from a first communication device of the
`user. The first authentication factor includes a password. The
`method further includes a step of receiving a second authen
`tication factor. The second authentication factor may include,
`for example, a device identifier of the first communication
`device of the user, or data transmitted to or received from a
`second communication device of the user. The method also
`includes a step of authenticating the user based on the
`received authentication factors. The present invention, in an
`illustrative embodiment, advantageously facilitates deploy
`ing two-or-more-factor authentication in everyday consumer
`e-commerce, without requiring new hardware or software.
`This makes it practical for widespread use.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 is a block schematic diagram of a conventional
`computer system.
`FIG. 2 are information flow diagrams of authentication
`process information flows according to various embodiments
`of the present invention.
`FIG. 3 are information flow diagrams of authentication
`process information flows for attempted man in the middle
`attacks according to one embodiment of the present inven
`tion.
`FIG.4, consisting of FIGS. 4A, 4B, 4C and 4D, is a flow
`chart illustrating a method of authenticating one or more
`users using two or more factors according to one embodiment
`of the present invention.
`FIG. 5 is a flowchart illustrating a method of identifying
`and implementing the transfer method to transfer information
`
`IPR2018-00067
`Unified EX1013 Page 9
`
`

`

`US 8,751,801 B2
`
`3
`from a mobile device to a server and vice versa according to
`one embodiment of the present invention.
`FIG. 6 is a flowchart illustrating a method of performing
`additional authentication steps that involve biometric authen
`tication according to one embodiment of the present inven
`tion.
`FIG. 7 is a system for authenticating a user using two or
`more factors according to one embodiment of the present
`invention.
`FIG. 8 is a flowchart illustrating a method of receiving a
`request and responding to it according to one embodiment of
`the present invention.
`FIG.9 is a flowchart illustrating a method of authenticating
`the user and the request according to one embodiment of the
`present invention.
`
`DETAILED DESCRIPTION OF A PREFERRED
`EMBODIMENT
`
`10
`
`15
`
`25
`
`30
`
`4
`The present invention includes a system and method of
`two-factor or three-factor authentication that can be deployed
`without requiring any software or hardware that the typical
`Internet user doesn't already possess, using:
`Device ID as a Credential Placing an identifier on the
`user's computer (or deriving it from the computer) in order to
`authenticate the device and use it as a second factor of authen
`tication.
`Phone as a Hardware Token. Using a telephone or other
`commonly-held communication device (other than the user's
`computer) as a second factor of authentication.
`These two methods can be used independently or in com
`bination. For instance, an entity can choose to use only a
`device ID as a second-factor authentication for most interac
`tions with a user. But it might choose to require the phone as
`a second-factor authentication for certain activities (such as
`registering a computer), permissions (such as writing data
`rather than viewing data), or transactions (such as high-dol
`lar-value transactions).
`In this way, the increased security of second-factor authen
`tication using the device ID can be added to most user inter
`actions, without changing the user experience at all. And even
`higher-security second-factor authentication using the phone
`can be added to a few critical interactions, without requiring
`any new software to be installed or any new hardware to be
`distributed.
`A) Device ID as a Credential
`Most users access the Internet predominantly from a small
`number of computing devices. If an entity can identify the
`devices used by each user, it can use the device ID as a second
`authentication factor. Then, an attacker not only has to obtain
`a user's password but also has to gain access to one of the
`user's computing devices (or to the device ID). The use of
`password and device ID can create stronger, two-factor
`authentication.
`Device IDs can be unprotected, software-protected or
`hardware-protected. Unprotected device IDs are simply data
`stored on the machine, which can be accessed by anyone—
`authorized or unauthorized who has the ability to read data
`stored on the machine. The security of the device ID can be
`protected by hardware or software, which either (a) restricts
`access to that data only to authorized requesters and/or (b)
`denies direct access altogether, and only allows indirect
`access to that data to be used in a cryptographic exchange to
`generate a session key.
`Browser and browser-related software that is already
`installed on most users’ computers today can be utilized to
`create software-protected device IDs that are relatively diffi
`cult to misappropriate. For example, most current browsers
`Support secure cookies. Secure cookies are strings of data that
`a site may store on a user's computer, which the browser
`Software will not subsequently reveal to any sites except those
`from the originating domain or sub-domain of the originating
`site.
`Cookies are generally used to recognize users in order to
`pre-populate data fields and/or to maintain sessions. But
`cookies can also be used as a device ID. A site may place a
`unique secure cookie on a user's machine to create a soft
`ware-protected device ID which unauthorized sites cannot
`access, and therefore cannot copy and use to impersonate the
`device. When the user signs on, the site can access the cookie,
`compare it to the copy of the user's cookie stored in the site's
`database and, if it matches, have a high level of assurance that
`the computer being used is the user's computer.
`This creates a simple mechanism for creating two-factor
`authentication for Internet commerce—without additional
`hardware or software. The device ID protects against an
`
`The present invention may be implemented as computer
`Software on a conventional computer system. Referring now
`to FIG. 1, a conventional computer system 150 for practicing
`the present invention is shown. Processor 160 retrieves and
`executes Software instructions stored in storage 162 Such as
`memory, which may be Random Access Memory (RAM) and
`may control other components to perform the present inven
`tion. Storage 162 may be used to store program instructions or
`data or both. Storage 164. Such as a computer disk drive or
`other nonvolatile storage, may provide storage of data or
`program instructions. In one embodiment, storage 164 pro
`vides longer term storage of instructions and data, with stor
`age 162 providing storage for data or instructions that may
`only be required for a shorter time than that of storage 164.
`Input device 166 Such as a computer keyboard or mouse or
`both allows user input to the system 150. Output 168, such as
`a display or printer, allows the system to provide information
`Such as instructions, data or other information to the user of
`the system 150. Storage input device 170 such as a conven
`tional floppy disk drive or CD-ROM drive accepts via input
`172 computer program products 174 such as a conventional
`floppy disk or CD-ROM or other nonvolatile storage media
`that may be used to transport computer instructions or data to
`the system 150. Computer program product 174 has encoded
`thereon computer readable program code devices 176, such
`as magnetic charges in the case of a floppy disk or optical
`encodings in the case of a CD-ROM which are encoded as
`program instructions, data or both to configure the computer
`system 150 to operate as described below.
`In one embodiment, each computer system 150 is a con
`ventional SUN MICROSYSTEMS ULTRA 10 WorkStation
`running the SOLARIS operating system commercially avail
`able from SUN MICROSYSTEMS, Inc. of Mountain View,
`Calif., a PENTIUM-compatible personal computer system
`Such as are available from DELL COMPUTER CORPORA
`55
`TION of Round Rock, Tex. running a version of the WIN
`DOWS operating system (such as 95, 98, Me, XP, NT or
`2000) commercially available from MICROSOFT Corpora
`tion of Redmond Wash. or a Macintosh computer system
`running the MACOS or OPENSTEP operating system com
`60
`mercially available from APPLE COMPUTER CORPORA
`TION of Cupertino, Calif. and the NETSCAPE browser.com
`mercially
`available
`from
`NETSCAPE
`COMMUNICATIONS CORPORATION of Mountain View,
`Calif. or INTERNET EXPLORER browser commercially
`available from MICROSOFT above, although other systems
`may be used.
`
`45
`
`35
`
`40
`
`50
`
`65
`
`IPR2018-00067
`Unified EX1013 Page 10
`
`

`

`5
`attacker with a stolen password, and the password protects
`against an attacker with unauthorized access to the user's
`computer. The attacker must now have both a stolen password
`and access to the user's computer.
`The primary issues with this method are the follows:
`1) How to protect against a man-in-the-middle attack?
`2) How to protect against malicious Software on the user's
`computer?
`3) What to do when the user erases the cookie from his
`computer?
`4) How to allow secure registration of a new computer?
`1) Man-in-the-Middle
`In a man-in-the-middle attack, the attacker inserts himself
`between the user and the entity and replays information it
`receives from one to the other. For instance, an attacker might
`lure a user to a fake site which looks like the entity's real site.
`The fake site can then request the user to provide private
`information Such as the user's password. This much can be
`done with simple phishing techniques, without requiring
`man-in-the-middle techniques. But if the user contempora
`neously expects to see private information from the real site,
`the attacker must become a man-in-the-middle. For instance,
`if the user expects to see his PassMark (referred to as “cus
`tomization information” in the related applications) from the
`real site before he enters his password, the attacker must
`collect and replay information between the user and the real
`site, like this:
`When the user provides his username to the fake site, the
`fake site replays it to the real site. When the real site then
`provides the user's PassMark to the fake site, the fake site
`replays the PassMark to the user. And when the user then
`provides his password to the fake site, the fake site replays the
`password to the real site.
`This type of attack can be automated at the fake site, so that
`the replays are fast and undetectable. The result is that the
`fake site can steal the user's password and PassMark, and
`thereafter masquerade as the user on the real site.
`Device IDS protect against this type of man-in-the-middle
`attack by identifying the user's computer. Because the user's
`computer will not provide the device ID to a computer from
`an unauthorized domain, the fake site cannot access the
`device ID and therefore cannot replay the device ID to the real
`site. Because the real site will not display the user's PassMark
`without seeing the user's device ID, the real site will not
`provide the PassMark (or other private information) to the
`fake site, and the man-in-the-middle attack is prevented.
`Thus, device IDs perform two important functions. First,
`they provide an easy way to implement two-factor authenti
`cation, and second, they provide protection against man-in
`the-middle attacks.
`2) Malicious Software
`Although the browser software will not allow unauthorized
`sites to access a secure cookie, it is Vulnerable if malicious
`Software is installed on the user's computer which compro
`mises the browser software or copies the data in the cookie.
`Traditional defenses against malicious software are to (a)
`educate users to take prudent steps to avoid installing
`untrusted Software on their computers, such as not opening
`email attachments from unknown senders, and (b) encourage
`the use of anti-virus software which attempts to identify and
`eliminate malicious Software.
`One method to mitigate the impact of stolen device IDs is
`for the site to modify the device ID upon each new session.
`This way, ifa device ID is stolen, once the site is subsequently
`visited by both the user and the attacker, the site will see a
`prior version of the device ID and therefore know that the
`device ID has been stolen. It will not be able to tell which
`
`10
`
`15
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 8,751,801 B2
`
`6
`visitor is the user and which is the attacker, but it will be able
`to shut down both copies of this device ID and separately
`re-establish a new registration with the user.
`As an additional defense against malicious Software steal
`ing the device ID, the entity can utilize other attributes of the
`user's computer. Device IDs can contain or be linked to
`identifying information about the user's computer, Such as
`the IP address or range from which it connects to the internet.
`This can mitigate the risk of another computer from imper
`Sonating the user's computer, even if the device ID is stolen.
`Optionally, software can be installed which interrogates
`the computer's components (such as a MAC address), dis
`tributes itself randomly on the hard disk, or takes other actions
`to avoid being copied or compromised. If the Software can
`write to the user's computer's hard drive, the site can instruct
`the software to store data in a variety of locations in files with
`unpredictable names. Then the site can make requests for
`unpredictable portions of that data upon each authentication,
`simultaneously changing other portions of the stored data.
`Ultimately, with enough time and Sophistication, an attacker
`who can install malicious Software on the user's computer can
`theoretically reverse engineer and defeat any Software-only
`approach to store a device ID on the computer. But this can be
`made difficult and time-consuming.
`3) Diversified Device IDs
`One difficulty with software-protected device IDs such as
`cookies, is that they are sometimes erased by the user or
`unintentionally overwritten by the site. One approach which
`allows recovery in the instance of the erasure of a device ID,
`is to place multiple device IDs on each computer.
`The first method is to place secure cookies from multiple
`domains (each controlled by the site) on the device. Then, if
`one cookie is erased but the site can read another cookie, it can
`still authenticate the device and can also restore the erased
`cookie.
`The second method is to create device IDs of multiple
`types, utilizing secure cookies, Flash shared objects, and
`other mechanisms which function similarly to allow data to
`be stored on the user's computer which is Subsequently acces
`sible only by authorized sites. Then, for instance, if all the
`cookies are erased, the site can authenticate the device with a
`Flash stored object and also restore the erased cookies.
`Optionally, software-protected device ID mechanisms can
`also be included in software that the entity or third-party may
`have installed on a user's computer, or may be offered to the
`user as a separate software installation.
`By diversifying the number and type of device IDs stored
`on each computer, the site can significantly decrease the
`likelihood that all of the device IDs will be erased at the same
`time.
`In addition, the method, location and originating domain of
`some of the device IDs can be varied by the entity in an
`unpredictable fashion, making the task of identifying and
`copying the device IDs more difficult, even if malicious soft
`ware is installed on the user's computer.
`If some but not all of the device IDs are present, the entity
`can choose to monitor the activity more closely or take pre
`cautionary or restrictive measures based on the lower strength
`of the authentication.
`4) Registration and Roaming
`The use of a device ID as an authentication factor poses
`three related questions: (1) How to register the initial device
`for a user, (2) How to re-register the device if all of the device
`IDs are erased, and (3) how to register a new device for the
`same user. Some methods for registering devices are:
`
`IPR2018-00067
`Unified EX1013 Page 11
`
`

`

`US 8,751,801 B2
`
`10
`
`15
`
`25
`
`35
`
`7
`(a) Register the initial device simultaneously with the ini
`tial registration of the user, when that registration is done
`over the Internet. (Initial registration only.)
`(b) Register the initial device of a previously-registered
`user upon first use. (Initial registration only.)
`(c) Require additional infrequently-requested personal
`information, Such as mother's maiden name, to be pro
`vided when registering or re-registering a device.
`(d) Pre-establish infrequently-used or one-time-use codes
`from a previously registered device, to be used to regis
`ter a new device. (New registrations and re-registrations
`only.)
`(e) Confirm a new device registration after-the-fact from a
`previously registered device. (New registrations and
`Some re-registrations only.)
`(f) Require an out-of-band confirmation when registering
`or re-registering a device. Out-of-band confirmation can
`be accomplished, often in a quick and automated fash
`ion, by sending a code to the user via a different com
`munication channel (such as email, phone, fax, instant
`messaging, or postal mail) which the user must retrieve
`and relay back to the site.
`(g) Require an out-of-band communication which contains
`a special Internet address (URL) which the user must
`navigate to in order to register the computer.
`Any of the methods above are reasonable policies for cer
`tain levels of security. However, methods (a) through (f) are
`potentially vulnerable to man-in-the-middle attacks. When
`registering a computer, a device ID does not already exist on
`30
`the computer, and therefore the device ID cannot be used to
`protect against man-in-the-middle attacks. If, for instance, a
`user is lured to a fake site posing as the real site, the fake site
`can simultaneously attempt to log in to the real site. Then it
`can request the same information from the user that the real
`site requests from it, and relay that information to the real site.
`In this way, the fake site can trick the real site into placing a
`device ID on the fake site's computer which the real site will
`subsequently identify as a legitimate device ID of the user.
`In the absence of a device ID, the primary way to protect
`against Such a man-in-the-middle attack is to educate the user
`to be sure to type in a known-good Internet address when
`navigating to a site to register a computer. However, rather
`than relying on the user to observe this preventative measure,
`the entity can enforce adherence by implementing method
`(g).
`In method (g), the entity sends a “registration URL to the
`user via a pre-registered out-of-band communication channel
`Such as email, instant messaging or phone. Since the user
`must navigate to that specific URL in order to register the
`computer, the entity can ensure that the user—even if previ
`ously lured to a fake site will have navigated to the real site
`before registering the computer. With this assurance that it is
`dealing directly with the user, the entity can then place a
`device ID onto the user's computer.
`To protect against man-in-the-middle attacks against the
`registration URL, the URL can be a special URL varied,
`randomized or customized for each registration—so that an
`attacker can not know or predict the URL. Otherwise, an
`attacker which had lured a user to a fake site could itself
`navigate to the URL and mount a man-in-the-middle attack
`by repla