GTL 1014
`IPR of U.S. Patent 9,007,420
`
`0001
`
`

`
`US 9,064,257 B2
`Page 2
`
`(56)
`
`References Cited
`
`OTHER PUBLICATIONS
`
`“A Novel Approach for Ear Recognition Based on ICA and RBF
`Network”, Zhang et al., 2005, Machine Learning and Cybernetics,
`Proceedings of 2005 International Conference, vol. 7, pp. 45 1 1-45 15.
`“Access Control System with Hand GeometryVerification and Smart
`Cards” Sanchez-Reillo et al., IEEE AES Systems Magazine, Feb.
`2000.
`“Acoustic Ear Recognition for Person Identification,” Akkermans et
`al., Automatic Identification Advanced Technologies, 2005, Fourth
`IEEE Workshop, pp. 219-223.
`“An Approach to Feature Selection for Keystroke Dynamics Systems
`Based on Pso and Feature Weighting,” Azevedo et al, Evolutionary
`Computation, CEC 2007, IEEE Congress, pp. 3577-3584.
`“An Introduction to Near-Field Communication and the Contactless
`Communication API,” C. Enrique Ortiz, sun, Jun. 2008, available at
`http://j ava.sun.com/developer/technicalA1ticles/j avame/nfc/.
`“Appearance-Based Facial Recognition Using Visible and Thermal
`Imagery: A Comparative Study”, Selinger et al., 2003.
`“Computer-Access Security Systems Using Keystroke Dynamics,”
`Bleha et al., IEEE Transactions on Pattern Analysis and Machine
`Intelligence, vol. 12, No. 12, pp. 1217-1222, Dec. 1990.
`“Ear Recognition by Means of a Rotation Invariant Descriptor,”
`Fabate et al., Pattern Recognition, 2006, ICPR 2006, 18th Interna-
`tional Conference, vol. 4, pp. 437-440.
`“Evaluating the Reliability of Credential Hardening Through Key-
`stroke Dynamics,” Bartlow and Cukik, Software Reliability Engi-
`neering, 2006, ISSRE ’06. 17th International Symposium, pp. 117-
`126.
`“Face Recognition: Features Versus Templates,” Brunelli and Pog-
`gio, IEEE Transactions on Pattern Analysis and Machine Intelli-
`gence, vol. 15, No. 10, pp. 1042-1052, Oct. 1993.
`“Human Ear Recognition in 3d,” Chen and Bhanu, IEEE Transac-
`tions on Pattern Analysis and Machine Intelligence, vol. 29, No. 4, pp.
`718-737, Apr. 2007.
`
`“Human Identification Based on 3d Ear Models,” Cadavid and
`Abdel-Mottaleb, Biometrics: Theory, Applications, and Systems,
`2007. BTAS 2007, First IEEE International Conference, pp. 1-6.
`Internet X.509 Public Key Infrastructure Certificate and Certificate
`Revocation List (CRL) Profile, RFC 5280 (Proposed Standard,) Coo-
`per et al., 2008.
`“Multimodal Recognition Based on Face and Ear”,Yuan et al., Wave-
`let Analysis and Pattern Recognition, 2007 ICWAPR ’07, Interna-
`tional Conference, vol. 3, pp. 1203-1207.
`“Multi-View Ear Shape Feature Extraction and Reconstruction,” Liu
`and Yan, Signal-In1age Technologies and Internet-Based System,
`2007, SITIS ’07 Third International IEEE Conference, pp. 652-658.
`“Personal Identification Based on Iris Texture Analysis” Ma et al.,
`IEEE Transactions on Pattern Analysis and Machine Intelligence,
`vol. 25, No. 12, pp. 1519-1533, Dec. 2003.
`Practice Note: Examples of Financial Services Using Mobile Phones,
`World Wide Web
`http://www.ictregulationtoolkit.org/en/
`PracticeNote.3096.htrnl.
`“Rapid Heterogeneous Connection Establishment: Accelerating
`Bluetooth Inquiry Using IrDA”, Ryan Woodings et al., Proc. of the
`Third Annual IEEE Wireless Communications and Networking Con-
`ference (WCNC) 2002, vol. 1, Orlando, Florida, Mar. 2002, pp.
`342-349.
`“The Transformational Potential of M-Transactions”, Vodaphone
`Group PLc, 2007.
`“User Authentication Through Typing Biometrics Features,” Araujo
`et al., IEEE Transactions on Signal Processing, vol. 53, No. 2, pp.
`851-855, Feb. 2005.
`“Using 2d Wavelet and Principal Component Analysis for Personal
`identification Based on 2d Ear Structure,” Nosrati et al. 2007, Intel-
`ligent and Advanced Systems, ICIAS 2007, International Confer-
`ence, pp. 616-620.
`“Visible-Spectrum Biometric Retina Recognition,” Borgen et al.,
`2008, International Conference on Intelligent Information Hiding
`and Multimedia Signal Processing (IIHMSP2008) pp. 1056-1062.
`Wizzit Has Done Its Homework, Says Mphahlele World Wid Web,
`Crotty,
`2005,
`http://www.nextbillion.net/archive/files/
`Wizzit%20Business%20Report.pdf.
`
`* cited by examiner
`
`0002
`
`0002
`
`

`
`U.S. Patent
`
`Jun. 23, 2015
`
`Sheet 1 of 14
`
`US 9,064,257 B2
`
`
`
`Ru‘;-':'f?‘$»I~5>I$57 9&1
`
`'*:$$fim§
`
`0003
`
`0003
`
`

`
`U.S. Patent
`
`Jun. 23, 2015
`
`Sheet 2 of 14
`
`US 9,064,257 B2
`
`3
`
`
`3£§
`
`
`
`0004
`
`0004
`
`

`
`U.S. Patent
`
`Jun. 23, 2015
`
`Sheet 3 of 14
`
`US 9,064,257 B2
`
`Ewééareszrzmmm
`
`S
`j¥31§L{i"?.
`
`'3
`
`‘§7¥?z.T:v~:rz:«:‘2A£‘§é».=tis::t§
`
`0005
`
`0005
`
`

`
`U.S. Patent
`
`Jun. 23, 2015
`
`Sheet 4 of 14
`
`US 9,064,257 B2
`
`
`
`’§‘??';¥'{’?§,._
`
`j,§§3,-1T:':';s;::,:,.>;.*;:§;§é:‘::::~:
`
`:%%:z‘:s:?§.
`
`ii}-»'::ies::::*;,;=;::-§:.§:::::z ’§3‘:;;T:::az;:§:i':-a:‘:«;::.s;
`
`0006
`
`0006
`
`

`
`U.S. Patent
`
`Jun. 23, 2015
`
`Sheet 5 of 14
`
`US 9,064,257 B2
`
`
`
`Aaifiarfiy
`
`::'¥3§3£‘§3
`
`fiasréifiaafize
`%fim,§i¥
`
`0§3?i<°§‘efi’§:, £33 §§ig:g:::3%;;.%;:;;§
`
`0007
`
`0007
`
`

`
`U.S. Patent
`
`Jun. 23, 2015
`
`Sheet 6 of 14
`
`US 9,064,257 B2
`
`
`
`‘§3?¥”.§:£‘I§.. {:2
`
`‘§?‘£::i:§s::
`
`'
`
`0008
`
`0008
`
`

`
`U.S. Patent
`
`Jun. 23, 2015
`
`Sheet 7 of 14
`
`US 9,064,257 B2
`
`0009
`
`0009
`
`

`
`U.S. Patent
`
`Jun. 23, 2015
`
`Sheet 8 of 14
`
`US 9,064,257 B2
`
`_._
`
`¢
`
`K
`
`V’
`
`‘_
`
`
`
`..
`
`0010
`
`0010
`
`

`
`U.S. Patent
`
`Jun. 23, 2015
`
`Sheet 9 of 14
`
`US 9,064,257 B2
`
`§§‘;§3§;§:§:.§; ‘§ii?,i;§§:i§§€fI:§E:
`
`3;s,==~§§;%z
`
`:if§:.:é:
`
`""¥'°z":>i2:‘:;,;~:;;>::.s'.A:;*.2‘::%'.€:‘«-3-2
`
`-§§..z§:i§::.§:3r%i.:§
`
`0011
`
`0011
`
`

`
`U.S. Patent
`
`Jun. 23, 2015
`
`Sheet 10 of 14
`
`US 9,064,257 B2
`
`
`
`
`
`§‘?i§{iI%,‘ii.{Ii3§si;t:::.::°:::*%ie;:’7§7:*2::;‘;.::e;:::;£:izmzfs§§*2$:‘;7zs;:s:;t;s:zs;
`
`
`
`
`
`0012
`
`0012
`
`

`
`U.S. Patent
`
`Jun. 23, 2015
`
`Sheet 11 of 14
`
`US 9,064,257 B2
`
`
`
`§3”9.'k§§}?2 £3?
`
`
`
`.55
`
`s;¥.,:,j;,.,
`
`§‘*i¥3I?:} 3.
`
`i”*{}:.f§
`
`‘7§.°::’zm?a2::a:i.§.:.::;2’.:
`
`0013
`
`0013
`
`

`
`U.S. Patent
`
`Jun. 23, 2015
`
`Sheet 12 of 14
`
`US 9,064,257 B2
`
`maéwimfi
`
` “§“2ss*.s«az>ssa:ssi"s‘ca:sa .»¢'ixs;z§i':eea':§$§g i.
`
`
`
`wage.-1 maaszérsgg
`
`hi
`
`KS‘, 33 E3?
`
`{Rf}?£i£T$:1§3?T::#3‘¥‘§?i*é> "§::%:%;§%:¥;‘?{§{.>’¥.f§.
`
`0014
`
`0014
`
`

`
`U.S. Patent
`
`Jun. 23, 2015
`
`Sheet 13 of 14
`
`US 9,064,257 B2
`
`
`
`
`*%%%%@*
`HH,,
`
`_. w§¥%é., 8§i3&T£3f3§?%, aim,
`
`
`
`"$’ra§:s~.&.<:§2as¢':: §£i:£§?¥§3§.%£§:
`
`>;s£f3A:*£. rm‘ {I%'ff?is,.-:3: §§;:::2:::"§,r I :::'».,;;=ze..=:».,f°-kmzfz
`wwd-
`
`0015
`
`0015
`
`

`
`U.S. Patent
`
`Jun. 23, 2015
`
`Sheet 14 of 14
`
`US 9,064,257 B2
`
`
`
`$?§:m°i?‘*a=2§:%1, afzsi,
`
`i¥45£{.:3‘:’.
`
`"%.é“:2s2::::.§%‘i.
`
`'§f‘?:r%z:;m:s2:;;:§:;%—:.3::'1
`
`”fififl&%$§§fi@$wfiW
`
`§%xm&$£xm¥§§
`
`0016
`
`0016
`
`

`
`US 9,064,257 B2
`
`1
`MOBILE DEVICE TRANSACTION USING
`MULTI-FAC TOR AUTHENTICATION
`
`CROSSREFERENCE1I)RELATED
`
`APPLICATION(S)
`
`The present application claims priority from U.S. Provi-
`sional Appl. No. 61/409,151, filed on Nov. 2, 2010, herein
`incorporated by reference in its entirety.
`
`BACKGROUND OF THE INVENTION
`
`1. Field of the Invention
`
`This invention relates to the field of data security, authen-
`tication, as well as biometrics. It specifically relates to multi-
`factor authentication for conducting transactions, using a
`handheld device. It is also related to cryptography and key
`exchange encryption techniques such as symmetric and
`asymmetric hashing and encryption.
`2. Description of the Related Art
`Mobile devices such as smartphones, personal digital
`assistants (PDAs), as well as many other handheld devices are
`being used as authentication devices for financial as well as
`access transactions. In some countries these devices are pro-
`viding the means for cash transactions in the same way a debit
`card is used. Some African countries have even been using
`these devices as prepaid credit devices which may be used for
`cash transactions simply by having the credit transferred from
`one phone to another. These are mostly done using the mobile
`network.
`
`ICT Regulation Toolkit is a toolkit which is generated by
`the Information for Development Program (InfoDev) and the
`International Telecommunication Union (ITU). A Practice
`Note [ICT Regilation Toolkit, 2011] gives many different
`examples of financial services which are available through
`the use ofa mobile phone. These include, Branchless Banking
`Models, such as the WIZZIT service [Crotty, 2005] in South
`Africa, Mobile Payment systems such as M-PESA in Kenya,
`Globe Telecom G-Cash service in the Philippines, and Air-
`time Transfers [Vodafone Group Plc., 2007] in Egypt, South
`Africa, and Kenya. See [ICT Regilation Toolkit, 2011] for
`details.
`
`However, the listed transactions currently rely on one or
`two of the following two authentication factors:
`1. Possession of an item (something one owns).
`2. Knowledge of an fact (something one knows).
`In the scenario ofParagraph 2, the phone is being used as an
`item being owned (1st authentication factor). In this case, if
`the phone is stolen or used without permission, one or more
`transactions may take place before the phone may be deacti-
`vated or the credit may be blocked. In fact, technically, the
`possession of the phone is equivalent to the old standard of
`possessing currency.
`To reduce the chance ofthe fraud described in Paragraph 5,
`some implementations also require another factor in the form
`of something the person knows (2nd factor), such as a chal-
`lenge passcode. However, most such passcodes are simple to
`ascertain and to abuse in order to attain unlawful access to the
`
`funds associated with the telephone.
`
`SUMMARY OF THE INVENTION
`
`The present invention provides for methods and systems
`that perform electronic transactions utilizing mobile devices
`in conjunction with multi-factor authentication. The multi-
`factor authentication utilizes three types of authentication
`factors including:
`
`2
`
`1. Possession of an item (something one owns).
`2. Knowledge of an fact (something one knows).
`3. Identity (something one is).
`Of course it is preferred to use more than one authentica-
`tion method in each factor type. In order to be able to decide
`if the device of interest is in the possession of the target
`individual, one may use the Subscriber Identity which is
`stored in the form of an ID on the Subscriber Identity Module
`(SIM) on most phones. Most PDAs and other handheld
`devices also have similar network subscriber IDs.
`
`This invention will not only utilize the third factor in con-
`junction with the first two factors in order to increase the
`security of the device and to reduce the chance of providing
`unauthorized access to individuals, but it also provides meth-
`odologies for combining these sources of information to
`reduce the chance of fraud.
`
`As it will be made more clear, this new methodology may
`be used for many other similar authentication applications
`such as any financial transaction, any access control (to
`account information, etc.), and any physical access scenario
`such as doubling for a passport or an access key to a restricted
`area (office, vault, etc.). It may also be used to conduct remote
`transactions such as those conducted on the Internet (E-Com-
`merce, account access, etc.). In the next section this multi-
`factor authentication is described further.
`
`For the second factor (knowledge of a fact), as an example,
`a challenge in the form of a traditional passcode may be
`requested, in which case it is usually typed in, or depending
`on the available input devices, facial expressions (for cam-
`eras), natural language understanding or a repeated phrase,
`through a speech recognizer for a microphone input, a hand-
`written signature such as described by [Beigi, 2009] used
`with a touchpad or a pen may be used along with other
`methods, some of which are described in the section describ-
`ing the authentication procedure, starting at Paragraph 40.
`For the third factor (something one is), biometric tech-
`niques are used. Many different biometric methods may be
`used, such as those listed in the Biometric challenge section,
`starting on Paragraph 63. Some such techniques are Speaker
`Recognition, Image-Based or Audio-Based Ear Recognition,
`Face Recognition, Fingerprint Recognition, Palm Recogni-
`tion, Hand-Geometry Recognition, Iris Recognition, Retinal
`Scan, Thermographic Image Recognition, Vein Recognition,
`Signature Verification, Keystroke Dynamics Recognition. Of
`course a multi-modal biometric recognition is preferred,
`since it reduces the chance of errors due to technological
`shortcomings and fraud.
`Several methodologies will be presented by this invention
`in the process ofcombining the above elements from the three
`possible factors, in order to reduce the chance of fraud.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 describes the registration process. This is the pro-
`cess that takes place once, either when the user has first
`activates the device or once for each new security level and
`access credential which is added.
`
`FIG. 2 shows the components of a generic smart device
`such as a smartphone, PDA, etc.
`FIG. 3 describes the process of hashing the subscriber ID
`(S) and the biometric models, Bn:ne{1, 2, .
`.
`.
`, N}, such that
`they are prepared for the registration with the CA or verified
`before usage.
`FIG. 4 shows the process of encrypting and decrypting the
`hashed data.
`
`FIG. 5 describes the process of digitally signing the refer-
`ence data by the Certificate Authority.
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`0017
`
`0017
`
`

`
`US 9,064,257 B2
`
`3
`FIG. 6 describes the validation process of the reference
`data on the phone at the time of the authentication.
`FIG. 7 describes the serial validation process for multiple
`certificate authorities.
`
`FIG. 8 describes the parallel validation process for multiple
`certificate authorities.
`
`FIG. 9 describes the process of registration with a transac-
`tion authority such as a credit card company in order to be able
`use their transaction services.
`
`FIG. 10 describes the generic transaction process through a
`Point of Service vendor in conjunction with the registered
`transaction authority relevant to this transaction. The POS
`may be a vendor who sells goods, provides services, or an
`access point.
`FIG. 11 describes a point of sale transaction employing
`multi-factor authentication in conjunction with a purchaser’ s
`mobile device.
`FIG. 12 describes a web-based electronic commerce trans-
`
`action utilizing multi-factor authentication in conjunction
`with a purchaser’s mobile device through the Internet.
`FIG. 13 describes a process to realize an electronic pass-
`port into a place.
`FIG. 14 describes a process in which the authentication
`techniques may be used to unlock a vault, providing access.
`
`DETAILED DESCRIPTION OF THE INVENTION
`
`4
`
`for communication between the user and the phone and some
`of which may be used to capture biometric information from
`the user to be processed as an extra authentication factor.
`Some of these devices have dual purposes (communication
`and biometric), such as a microphone 16 which may be used
`for telephone conversations as well as capturing the speech of
`the individual for speaker recognition—see Paragraph 64.
`The camera 18 is another dual use sensor which may be used
`for taking pictures as well as obtaining images for doing
`image recognition as a biometric—see biometrics using
`imaging, starting with face recognition on Paragraph 69.
`Other biometric sensors such as a fingerprint sensor 20 may
`be added to devices for extra security.
`For instance, if the biometric of choice is fingerprint, then
`the PDA would have to have a fingerprint capture device.
`These requirements have been explored in the description
`below, for different biometrics.
`
`The Enrollment and/or Registration Stage
`
`10
`
`15
`
`20
`
`When the phone is registered (or at some later time), the
`owner of the device does a biometric enrollment and the
`model/models is/are built and stored on the device. These
`
`25
`
`models are generally representations of the features of the
`specific biometric of interest. Most biometric models do not
`store the actual features of the biometric. The models are
`
`The following is a system in which a person may use a
`Cellular (Mobile) Telephone, a PDA or any other handheld
`computer to make a purchase. This is an example only. The
`process may entail any type of transaction which requires
`authentication, such as any financial transaction, any access
`control (to account information, etc .), and any physical access
`scenario such as doubling for a passport or an access key to a
`restricted area (office, vault, etc.). It may also be used to
`conduct remote transactions such as those conducted on the
`
`Internet (E-Commerce, account access, etc.). In the process, a
`multi-factor authentication is used.
`
`In this narrative, the words, “PDA”, “device,” and “phone”
`are used interchangeably to indicate a Cellular (Mobile)
`phone, any Personal Digital Assistant (PDA), Personal Music
`Player (Assistant), or any portable electronic device capable
`of capturing a biometric and communicating with a computer
`and/or telephony network.
`As we will see later, one of the possible biometrics would
`be speech (speaker recognition). In this specific case, for
`example, the PDA of FIG. 2 would have to be able to capture
`audio and communicate with a network. Examples of such
`devices are cellular telephones with network access (WIFI,
`WAN, LAN, BlueTooth, etc.) and computational capabili-
`ties—e.g., iPhone, iPod, iPaq, any PDA with a microphone,
`etc.
`
`FIG. 2 shows the generic infrastructure of a mobile device
`(PDA). The device generally consists of a central processing
`unit (CPU) 8 which performs most of the computation, a
`persistent memory 6 which is used to store data for future use,
`a random access memory (RAM) 10 which is used for short
`term storage while a computation takes place or to load and
`run an application and its dynamic data segments, a sub-
`scriber identity model (SIM) device 12 which is used by
`telephone service providers to store the unique identity of the
`user account, S, a communication hardware 14 which spe-
`cializes in telephone, wireless, networking, and related opera-
`tions, peripheral hardware 22 which includes all other hard-
`ware used for the operation of the phone such as illumination,
`touchpad, switches, volume control, speakers, etc. In addi-
`tion, there are human interface sensors which are usually used
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`usually statistical parameters and other function representa-
`tions of the features captured at the enrollment process com-
`bined with statistical or function of features of some larger
`training sample from the biometric vendor. [Beigi, 2012],
`herein incorporated by reference in its entirety, provides an
`overview of biometric models as well as a detail treatment of
`
`speaker recognition as a biometric.
`The initial enrollment may need to be verified by a third
`party using a Public Key Infrastructure (PKI) such as the
`X.509 standard being used by most Internet applications and
`prescribed in detail in the ITU-T RFC 5280 [Cooper et al.,
`2008]. The noted third party may be a certificate authority,
`such as those which exist for issuing secure certificates, or
`may be another trusted institution, such as the service pro-
`vider, a bank or a notary. The enrollment may be certified
`using a secure key such as the digital certificate which is
`signed by an SSL certificate authority. It makes sense for this
`to be done by the Cellular telephone vendor who makes the
`sale or by his/her organization. See the Encryption and Key
`exchange section.
`Once the biometric enrollment is completed, the models
`for doing a biometric challenge are ready to enable the bio-
`metric authentication services on the phone.
`At this point, account information may be linked to the
`device/user through registration with a transaction authority
`FIG. 9 The difference between this step and the actual trans-
`action is that it allows for tailoring the multi-factor authenti-
`cation for the particular device/user in order to dictate the
`strength ofthe authentication. This strength may be varied for
`different user-transaction combinations. Each security level
`may have a special digital certificate associated with it and at
`the time of usage, the transaction authority may request dif-
`ferent levels of security (different credentials). For example,
`consider a MasterCard account and access as a country’s
`passport. The financial institution issuing the MasterCard,
`will conduct an Authentication as listed in the Authentication
`
`Procedure step and then will issue a secure certificate in the
`form of a key to the phone which will be saved by the tele-
`phone and associated with that account. The passport office
`will do the same, generating a passport certificate. The cre-
`dentials for obtaining these keys may be less or more stringent
`
`0018
`
`0018
`
`

`
`US 9,064,257 B2
`
`5
`depending on the security level. The level of security is inher-
`ent in the certificate which is issued.
`
`At this stage, the biometric enrollment and account linking
`is done. Let us assume that there is a MasterCard account
`
`certificate issued by bank A and saved on the device, the
`person’s passport is linked with the phone and the employer
`of the individual has linked in an account for accessing the
`office building and special parts of the company which
`require restricted access.
`Note that all the information is being stored in the form of
`encrypted keys in the phone and each key may only be deci-
`phered by the issuing authority who has the related private
`key used at the time of conducting the transaction. This is in
`contrast with holding the information on a server or servers
`which wouldhave to be distributed. A server-based solution is
`
`not viable since it requires constant communication with the
`place where the information is stored and may be fooled to
`release the information to unauthorized devices. In the situ-
`
`ation described here, once the linking is done, the possession
`of the device holding the keys also becomes important.
`For every account which is linked, a minimum requirement
`of the available authentication methods is picked. The autho-
`rizing institution sets the minimum requirements at the setup
`and the owner of the PDA may add extra authentication
`methods to apply more security. Each linked account may be
`set up to require a different combination of authentication
`methods. N.B ., see authentication methods for more informa-
`tion.
`
`The Transaction
`
`The transaction may be any process requiring authentica-
`tion such as a physical access control scenario such as a
`passport, an account access scenario using the Internet or a
`telephone network, etc. The following sales transaction is
`used to simplify the understanding of the process.
`1. The PDA is set to accept transactions by the owner at the
`time of conducting the transaction. We will call this the
`“ready mode.”
`2. The point of sale terminal (Cashier machine) discovers
`all the PDAs in ready mode. This discovery process may be
`done in one or more ofmany different possible methods, such
`as BlueTooth and IrDA discovery standards as well as the
`many wireless standards.
`3. Photo of the PDA owner (or his/her name or ID) appears
`on the cashier’s screen.
`
`4. The cashier picks the correct person’ s PDA from the list
`and the two machines (PDA and Cashier) are linked.
`5. The linking may be done on any network including a
`BlueTooth, a WIFI, Near Field Communication device, or
`WAN.
`6. The PDA owner receives notification for the transaction
`
`plus the challenge information.
`7. The customer picks a payment method from his PDA’s
`linked accounts.
`
`55
`
`8. The payment method triggers a combination of chal-
`lenges based on requirements which have been set in the set
`up stage by the PDA owner and the authorizing entity (e.g. the
`bank administering the credit card, the company allowing
`access to its premises, the passport agency, etc.).
`9. In the communication, the cashier checks for the certifi-
`cate key which has been linked with the transaction much in
`the same way that TLS and SSL work and check for the
`validity of the certificate. The cashier checks for the validity
`of the certificate of the customer through a network with the
`authorizing agency (much in the same way as a credit card
`
`60
`
`65
`
`6
`purchase is checked today). The certificate may be revoked at
`any time, at which instance, the transaction will fail.
`10. Challenges happen on the PDA and the results reported
`to the cashier.
`
`The Authentication Procedure
`
`The authentication process may check for the validity of
`the subscriber ID with an authority. Note that the authenticity
`of the subscriber ID has been validated by the validation
`process (Paragraph 51) and should only be checked by some
`transaction authority for validity.
`Based on the second authentication factor (something one
`knows), a challenge request may initiated by the point of
`service. This item may be designed to work seamlessly with
`a biometric challenge (see Speaker Recognition[Beigi, 2012]
`for example) or it may be entered using the keypad or any
`other data entry device, such as picking from a list of images,
`etc.
`The authentication also includes one or more biometric
`
`challenges [Beigi, 2012]: This item has been described below
`in detail, beginning in Paragraph 63.
`
`Registration with the Certificate Authorities
`
`FIG. 3 shows the primary process in the encryption, vali-
`dation, and registration of the authentication elements with
`the Certificate Authorities. In the figure, Yl.:Hl.O(l.):ie{0,
`1,
`.
`.
`.
`, N} denotes a hashing function [van Tilborg and
`Jajodia, 2011]. i:0 relates to the hashing function for the
`subscriber ID, S, and i:n:ne{ 1, 2,
`.
`.
`.
`, N} relates to the
`hashing functions which are used to hash the biometric mod-
`els (prototypes), Bn:ne{1, 2, .
`.
`.
`, N}. Technically, there it not
`necessary for these functions to be different, however, the
`mo st general case would call for different functions. Also, it is
`possible for the hashing function to just be the identity func-
`tion given by Equation 1.
`
`Y:I<2oéI<2o:H<2o=H<2o:X
`
`<1)
`
`The output of the hash function is a string of binary digits
`called the hash of X, HO().
`The following definitions are used to describe the digital
`signature of the information which is stored on the device to
`ensure the authenticity of the authentication references.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`Xié Authentication Reference Vie{0,1, .
`
`.
`
`. ,N}
`
`(2)
`
`, N}. The authentication
`.
`.
`where XO:S and Xn:Bn Vne{ 1, 2, .
`reference is also referred to as reference data herein.
`
`50
`
`Y1. denotes the output of the hash function applied on the
`authentication reference, X1,
`
`Y1; H,.(X,.) Vie{0,1, .
`
`.
`
`. ,N}
`
`(3)
`
`Assuming that there is a certificate authority [Cooper et al.,
`2008], [van Tilborg and Jajodia, 2011] whois used to sign the
`references, we denote that authority by CA and the private
`and public keys of that authority, as defined by the X.509
`standard [Cooper et al., 2008] for the Public Key Infrastruc-
`ture (PKI) are denoted by the following two variables respec-
`tively,
`
`RCA A Private key of the CA
`
`PCA A Public key ofthe CA
`
`(4)
`
`(5)
`
`In the same way as in Paragraph 46, there will be a private
`and public key pair which are generated on the PDA at the
`time of the registration, using the registration application.
`
`0019
`
`0019
`
`

`
`US 9,064,257 B2
`
`7
`This pair of keys is denoted by the following two variables,
`
`RPDA é Private key ofthe Device
`
`PPDA A Public key ofthe Device
`
`(6)
`
`(7)
`
`We need to define two functions which denote the encryp-
`tion and decryption of some data. These functions are defined
`as follows, using any encryption technique which may be
`desirable. Many such techniques are given by the X.509 stan-
`dard [Cooper et al., 2008] and a lot more are explained in
`detail in [van Tilborg and Jajodia, 2011].
`
`Z:E(R, Y) A Encryption function for Private key R and
`data Y
`
`D(P,Z) :D(P,Z):Y(Decryption function)
`
`where
`
`2,5 E(R, Y,-)Vie{0,1, .
`
`.
`
`. ,N}
`
`(8)
`
`(9)
`
`(10)
`
`FIG. 4 shows the generic encryption and decryption of the
`hashed data.
`
`FIG. 5 shows the signature process using the above defini-
`tions. It is important to note that the Certificate Authority
`(CA) never sees the raw subscriber ID, S, or the biometric
`models, B". The CA only receives an encrypted copy of the
`hashed data for each i, Zi. It also receives the public encryp-
`tion key of the registration application on the device, PPDA,
`such that it can decrypt the data and see the hashed data,Yl.. In
`addition, the credentials of the registration application are
`sent along much in the same way as a digital certificate is
`requested from the CA described in X.509. The credentials
`are used by the CA to decide if it should sign the hashed data
`for the device or not. We do not go into any detail about that
`since it is a well established process and different CAs have
`different procedures for that. Then the CA uses its private key,
`RCA, which is unknown to the PDA, to encrypt (sign) the
`hashed data, Yi. This signed data, Al.:ie{0, 1, .
`.
`.
`, N}, is then
`sent back to the registration application on the PDA, along
`with the public key ofthe CA, PCA. PCA is the certificate which
`is used by the PDA authentication applications in order to be
`able to decrypt the signed version of the hashed data, Al, in
`order to get a certified copy of the hashed reference, Yl.CA.
`Superscript CA means that this is the certified hash value of
`the reference data, X..
`The signed hashed values, Al, and the public key ofthe CA,
`PCA, are stored in the persistent memory of the device shown
`in FIG. 2.
`
`Validation of Reference Data
`
`FIG. 6 shows the validation process for the reference data.
`At the time of each transaction where authentication is nec-
`
`essary, this process of validation takes place. The data is
`retrieved from the persistent memory of the device and is
`decrypted to get the signed hash values of the different refer-
`ence data. Then the original reference data is retrieved by the
`authentication application from the persistent memory of the
`device and is hashed in the same manner as it was done in the
`
`hashing step of the registration defined in Paragraph 43.
`These two sets of hash values are then compare as prescribed
`by FIG. 6 to see if they match. If they match, the multi-factor
`authentication process will begin, described, beginning in
`Paragraph 40 and shown in FIG. 11, FIG. 12, FIG. 13, and
`FIG. 14 depending on the scenario at hand. In this authenti-
`cation process, as described, the subscriber ID, multiple bio-
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`8
`metrics, and multiple types of challenges are used to do the
`final multi-factor authentication of the individual, the device,
`and transaction.
`
`Multiple CA Signatures
`
`For more security conscious applications, it is possible to
`have multiple CAs sign the hash values. This may be done
`either in parallel or in series. For a series process, the hash
`values are sent to CAL Then the resulting signed data from
`CA1, Ail is sent to CA2 to receive A19, and so on. Finally,
`there will be an encrypted data with a series of M public keys
`associated with the M different CAs. In this case, the regis-
`tration application will store the order of signatures, O, in an
`encrypted file, using RPDA and stored in the persistent
`memory of the PDA, along with Al.M from the last (M”’)CA,
`and all M public keys, PCA’":me{1, 2, .
`.
`.
`,
`At the time of validating a data signed by a series of CAs,
`the authentication application will decrypt the order data, 0,
`from the persistent memory using PPDA and uses it to decrypt
`the series of encryptions in the reverse order, using Al.M and
`PCAM to get Al.M‘1 and so on until a Yl.CA is deciphered. See
`FIG. 7. The procedure of validation and authentication will
`then continue as prescribed in Paragraph 51.
`For a parallel signature process, each CA signs the sameYl.
`independently. In this case, allAl.’", PCA’”:me{ 1, 2, .
`.
`.
`, M} are
`stored. No specific order is necessary. At the validation step,
`all the hash values deciphered from the A17" and from the
`reference data would have to match. See FIG. 8.
`
`The multiple signature process may be used to store the
`different signed hash values at different
`locations. For
`example, if the device has access to network storage in L
`locations, it may send each of L signed hash values by L
`different CAs to these L locations, one of which is the per-
`sistent memory of the PDA. Then at the authentication step, it
`may try to retrieve as many copies of these hashed values as
`possible. Ifbecause ofnetwork or technical issues some ofthe
`L locations are not accessible, it can use down to a minimum
`prescribed number of different retrieved signed copies as it
`can. Then if the prescribed minimum locations is met and if
`all the hash values match with the data on the PDA, the device
`may go ahead with the authentication process.
`It is important to ensure that the applications in charge of
`the registration and authentication are genuine and certified.
`This may be done using standard digital certificates which
`have been described in detail in [van Tilborg and Jajodia,
`20