(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT)
`
`(19) World Intellectual Property
`Organization
`International Bureau
`
`
`
`(43) International Publication Date
`6 January 2005 (06.01.2005)
`
`(10) International Publication Number
`
`PCT
`
`WO 2005/001751 A1
`
`(51) International Patent Classification7:
`H04K 1/00, H04L 9/00
`
`G06K 9/00,
`
`(21) International Application Number:
`PCT/ U $2004/017545
`
`(22) International Filing Date:
`
`2 June 2004 (02.06.2004)
`
`(25) Filing Language:
`
`(26) Publication Language:
`
`English
`
`English
`
`(30) Priority Data:
`60/475,242
`
`2 June 2003 (02.06.2003)
`
`US
`
`(71) Applicant (for all designated States except US): RE-
`GENTS OF THE UNIVERSITY OF CALIFORNIA
`
`[US/US]; University of California, Los Angeles, 10920
`Wilshire Blvd, Suite 1200, Los Angeles, CA 90024—1406
`(US).
`
`(72) Inventors; and
`(75) Inventors/Applicants (for US only): VERBAUWHEDE,
`Ingrid, 1W. [i/US]; 1123 23rd Street, #C, Santa Monica,
`CA 90403 (US). SCHAUIWONT, Patrick, R. [ifUS];
`
`10439 Holman Avenue, Los Angelcs, CA 90024 (US).
`HVVANG, David, D. [ilUS]; 540 Kelton Avenue, #205,
`Los Angeles, CA 90024 (US). LAI, Bo—Cheng [ifUS];
`10125 Palms Boulevard, #204, Los Angeles, CA 90034
`(US). YANG, Shenglin [ifUS]; 3170 Sawtelle Boulevard,
`
`Apt. #203, Los Angeles, CA 90066 (US). SAKIYAMA,
`Kazuo [
`[US]; 3200 Sawtelle Boulevard, Apt.
`#202,
`Los Angeles, CA 90066 (US). FAN, Yi [ifUS]; 310 S.
`Kenmore Avenue, Apt. #202, Los Angeles, CA 90020
`(US). HODJAT, Alireza [ifUS]; 2624 Kansan Avenue,
`#14, Santa Monica, CA 90404 (US).
`
`KNOBBE,
`DELANEY, Karoline, A.;
`Agent:
`MARTENS, OLSON AND BEAR, LLP, 2040 Main
`Street, Fourteenth Floor, Iivine, CA 92614 (US).
`
`Designated States (unless otherwise indicated. for every
`kind of national protection available): AE, AG, AL, AM,
`AT, AU, AZ, BA, BB, BG, BR, BW, BY, BZ, CA, CH, CN,
`CO, CR, CU, CZ, DE, DK, DM, DZ, EC, EE, EG, ES, FI,
`GB, GD, GE, GH, GM, HR, HU, ID, IL, IN, IS, JP, KE,
`KG, KP, KR, KZ, LC, LK, LR, LS, LT, LU, LV, MA, MD,
`MG, MK, MN, MW, MX, MZ, NA, NI, NO, NZ, OM, PG,
`PH, PL, PT, RO, RU, SC, SD, SE, SG, SK, SL, SY, TJ, TM,
`TN, TR, TT, TZ, UA, UG, US, UZ, VC, VN, YU, ZA, ZM,
`ZW.
`
`[Continued on next page]
`
`(74)
`
`(31)
`
`(54) Title: SYSTEM FOR BIOMETRIC SIGNAL PROCESSING WITH HARDWARE AND SOFTWARE ACCELARATION
`
`,
`
`zoo
`
`401
`31°
`., ,
`.
`IRANSACTION
`REGISTER g AUTHsE’ii/lgi'im"
`THUMBPOD (22Account number
`Account number and amount
`fl»
`
`
`
`
`
`a Mutual authentication between register'and server (SET)
`
`Load shared sacral key K
`Generate authentication vector
`AV=RAND l SONA5$ AK l AMF | MAC“
`4“— <——\
`
`a
`Store RAND, SONHQAK, AMF. MAC“
`’1
`
`Perform fingerprint brometrlcs
`Generate shared secret key K=HASHm(temptute)
` ‘\400
`rGenerala authentication vector
`Verify identity of server
`RESTp
`
`
`——§———>. . “3*
`
`5
`
`4
`Increment SON”
`
`a
`
`<
`Transactioh complete message
`
`[D Verify identity at ThumbPod
`
`
`
`Increment SQNrs
`G
` (Optional) Streaming encryption with integrity check
`
`
`
`05/001751A1|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
`
`c (57) Abstract: A secure embedded system that uses cryptographic and biometric signal processing acceleration is described. In
`N one embodiment, the secure embedded system is configured as a Wireless pay—point protocol for brick—and—mortar and e—commerce
`applications in which biometric information is localized and does not require transmission of biometric data for authentication. In
`one embodiment, a keyegeneration function uses a dynamic key generator and static biometric components. In one embodiment, an
`embedded system design methodology provides hardware and software acceleration transparency.
`
`W0
`
`Apple 1 107
`
`Apple 1107
`
`

`

`WO 2005/001751 A1
`
`|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
`
`(84) Designated States (unless otherwise indicated, for every — before the expiration of the time limit for amending the
`kind of regional protection available): ARIPO (BW. GII,
`claims and to be republished in the event of receipt of
`GM, KE, LS, MW, MZ, NA, SD, SL, SZ, ’11, UG, ZM,
`amendments
`ZW), Eurasian (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM),
`
`European (AT’ BE” BG’ CI L CY” CZ” DE” DK’ EE’ ES” FT”
`FR’ GB’ GR HU* IE IT’ LU’ MC’ NL’ PL’ PT’ RO’ SE’ 31’
`SK’ TR)’ OAPI (BE BJ’ CF’ CG’ CI’ CM’ GA’ GN’ GQ’
`GW, ML, MR, NE, SN, TD, TG).
`Declaration under Rule 4.17:
`
`— of inventorship (Rule 4.17(iv)) for US only
`Published:
`
`— with international search report
`
`For two—letter codes and other abbreviations, refer to the "Guid-
`ance Notes on Codes andAbbreviations ” appearing at the begin-
`ning of each regular issue of the PCT Gazette.
`
`

`

`WO 2005/001751
`
`PCT/U52004/017545
`
`SYSTEM FOR BIOMETRIC SIGNAL PROCESSING WITH HARDWARE AND
`
`SOFTWARE ACCELERATION
`
`Reference to Related Application
`
`[0001]
`
`The present application claims priority benefit
`
`if US. Provisional
`
`Application No. 60/475,242,
`
`filed June 2, 2003,
`
`titled “SYSTEM FOR BIOMETRIC
`
`SIGNAL PROCESSING WITH HARDWARE AND SOFTWARE ACCELERATION,“ the
`
`entire contents of which is hereby incorporated by reference.
`
`Government Interest Statement
`
`Portions of the subject matter of this application were invented under a contract with
`
`an agency of the United States Government, under NSF contract No. 0098361.
`
`Field of the invention
`
`Background
`
`[0002]
`
`The present
`
`invention relates to systems using biometric signal
`
`processing for authentication in connection with a secure communication protocol.
`
`Description of the Related Art
`
`[0003]
`
`In February 2003, a computer hacker breached the security systems of Visa
`
`and MasterCard and accessed 5.6 million valid account numbers, which represents
`
`approximately 1% of all 574 million valid account numbers in the United States. Though the
`
`accounts were not used fraudulently, a burdensome recall and replacement of valid cards
`
`throughout many financial institutions was required. On the Internet, a number of black-
`
`market sites sell active credit card account numbers and expiration dates for a modest price.
`
`In brick-and-mortar credit card scenarios, photograph identification or signatures are
`
`.inconsistently checked in normal purchases; hence, fraudulent transactions are commonplace.
`
`These situations are just a few which expose the current flaw in traditional
`
`transaction
`
`

`

`WO 2005/001751
`
`PCT/US2004/017545
`
`protocols, which is mainly a flaw in authentication. Identity theft results in losses of well over
`
`a billion dollars a year for credit card issuers, and is even more widespread since the advent
`
`of e—commerce on the Internet. The primary reason for the continued success of identity theft
`
`is the lack of the ability to prove that an account
`
`is used by the genuine, authorized,
`
`consumer.
`
`Summary
`
`[0004]
`
`The present invention solves these and other problems by providing a
`
`secure embedded system that uses cryptographic and biometric signal processing to provide
`identity authentication. In one embodiment, the secure embedded system is configured as a
`
`wireless pay-point device, called a thumbpod, for brick-and-mortar and/or e-commerce
`
`applications. In one embodiment, the thumbpod localizes a sensitive biometric template and
`
`does not require transmission of biometric data for authentication. In one embodiment, a key-
`
`generation function uses a dynamic key generator and static biometric components. An
`
`embedded
`
`system design methodology
`
`known
`
`as
`
`hardware/software
`
`acceleration
`
`transparency is provided to improve performance'of the thumbpod. In one embodiment,
`
`acceleration transparency is provided in a systematic method to accelerate Java functions in
`
`both software and hardware of, for example, an encryption function.
`
`[0005]
`
`In one embodiment,
`
`the thumbpod is designed as a secure embedded
`
`device that provides a protocol for wireless pay-point transactions in a secure manner. The
`
`protocol uses secure cryptographic primitives as well as biometric authentication techniques.
`
`The security protocol used in the thumbpod is based on a protocol that uses the thumbpod as
`
`an interface between an authentication server and a user.
`
`[0006]
`
`In one embodiment, the thumbpod includes a microcontroller, a fingerprint
`
`image sensor, signal processing hardware acceleration, cryptographic hardware acceleration,
`
`and a memory module enclosed within a fomi factor similar to an automobile keychain
`
`transmitter. The thumbpod provides flexible communication via ports, such as, for example,
`
`a port for wireless communication and/or a wired port for fast wire-line communication. The
`
`wireless port can be, for example, an infrared port, a radio-frequency port, an inductive
`
`coupling port, a capacitive coupling port, a Bluetooth port, a wireless Ethernet port, etc. The
`
`

`

`WO 2005/001751
`
`PCT/U52004/017545
`
`wired port can be, for example, a USB port, a firewire port, a serial port, an Ethernet port, etc.
`The thumbpod can be used for a wide variety of authentication-related transactions, such as,
`
`for example, wireless credit card payments, keychain flash memory replacement, universal
`
`key functionality (house, car, office), storage of sensitive medical data, IR secure printing,
`etc.
`
`[0007]
`
`In one embodiment, a security protocol binds the user to the device
`
`through biometrics, combines biometrics and traditional
`
`security protocols, protects
`
`biometric data by keeping at least a portion of the biometric data in a protected form that does
`
`not leave the device, and provides that biometric calculations are provided on the device. In
`
`one embodiment, biometric algorithms are provided to fit
`
`a
`
`relatively constrained
`
`environment of embedded devices. In one embodiment, algorithms are provided in fixed
`
`point arithmetic.
`
`In one embodiment, memory storage optimization and hardware
`
`acceleration are provided by converting a least a portion of one or more software algorithms
`
`into hardware.
`
`Brief Description of the Drawings
`
`[0008]
`
`The various features of the present are described with reference to the
`
`following figures.
`
`[0009]
`
`Figure 1 shows layers of an embedded security protocol system.
`
`[0010]
`
`Figure 2 shows one embodiment of a thumbpod device.
`
`[0011]
`
`Figure 3A is a block diagram of an authentication protocol having a
`
`relatively strong one—way authentication protocol between the server and the device and a
`
`relatively week security protocol between and the device and the user.
`
`

`

`WO 2005/001751
`
`PCT/U52004/017545
`
`Figure 3B is a block diagram of an authentication protocol having a
`[0012]
`relatively strong two-way authentication protocol between the server and the device and a
`relatively strong security protocol between and the device and the user.
`
`~.
`
`[0013]
`
`Figure 4 is a further block diagram of one embodiment of the
`
`authentication protocol shown in Figure 3B.
`
`Figure
`[0014]
`authentication server.
`
`5
`
`shows
`
`authentication protocol vector generation in the
`
`[0015]
`Figure 2.
`
`Figure 6 shows authentication vector generation in the thumbpod device of
`
`[0016]
`
`Figure 7 shows generation of authentication functions F 1-F5.
`
`[0017]
`
`Figure 8 is a block diagram of the Rijndael CBC-MAC algorithm.
`
`[0018]
`
`Figure 9 is a block diagram of the Rijndael OFB-Counter algorithm.
`
`[0019]
`
`Figure 10 is a block diagram of the NIST minutia extraction flow
`
`algorithm the fingerprint identification system.
`
`[0020]
`
`Figure 11 shows window rotation in the fingerprint identification system.
`
`Figure 12 shows an example of an original
`[0021]
`identification system.
`
`image in the fingerprint
`
`[0022]
`binarization.
`
`Figure 13
`
`shows minutiae points in the image of Figure 12 after
`
`

`

`WO 2005/001751
`
`PCT/U52004/017545
`
`[0023]
`
`Figure 14 shows matching flow in the fingerprint identification system.
`
`[0024]
`
`Figure 15 shows local features of fingerprint minutia.
`
`[0025]
`
`Figure 16 is a chart showing the execution time for various operations in
`
`the minutia detection algorithm at the block diagram level.
`
`[0026]
`
`Figure 17 is a chart showing the execution time for various operations in
`
`the minutia detection algorithm at the instruction level.
`
`[0027]
`
`Figure 18 shows an example of the direction map.
`
`[0028]
`
`Figure 19 shows the relationships between execution time, error rate, and
`
`ETH in the fingerprint identification system.
`
`[0029]
`
`Figure 20 is a block diagram of a memory-mapped EFT accelerator.
`
`[0030]
`
`Figure 21 is a chart showing execution time for different embodiments of
`
`the fingerprint identification system.
`
`[0031]
`
`Figure 22 is
`
`a
`
`chart
`
`showing energy consumption for different
`
`embodiments of the fingerprint identification system.
`
`[0032]
`
`Figure 23 shows profiling results for
`
`the baseline algorithm in the
`
`fingerprint identification system.
`
`[0033]
`
`Figure 24 shows relationships between the pre-checking threshold and
`
`performance of the fingerprint identification system.
`
`

`

`WO 2005/001751
`
`PCT/US2004/017545
`
`[0034]
`
`Figure 25A is a chart comparing the execution time for the baseline and
`
`the optimized fingerprint matching systems.
`
`[0035]
`
`Figure 25B is a chart comparing the energy consumption for the baseline
`
`and the optimized fingerprint matching systems.
`
`[0036]
`
`Figures 26A-26F show various embodiments of hardware or software
`
`acceleration transparency.
`
`[0037]
`
`Figure 27 shows acceleration of the Rijndael algorithm using hardware
`
`and software acceleration.
`
`[0038]
`
`Figure 28A is
`
`a block diagram showing a functional model of
`
`hardware/software accelerator design.
`
`[0039]
`
`Figure 28B is a block diagram showing a benchmarkng functional model
`
`of hardware/software accelerator design.
`
`[0040]
`
`Figure 28C is a block diagram showing a transaction-level model of
`
`hardware/software accelerator design.
`
`[0041]
`Figure 28D is
`a block diagram showing an embedded software
`implementation model
`functional model of hardware/software accelerator design for a
`
`personal computer implementation.
`
`[0042]
`
`Figure 2813
`
`is
`
`a block diagram showing an embedded software
`
`implementation model of software accelerator design for a board-level implementation.
`
`

`

`W0 2005/001751
`
`PCT/U52004/017545
`
`[0043]
`
`Figure 28F is
`
`a block diagram showing an embedded software
`
`implementation model of hardware/software
`
`accelerator design
`
`for
`
`a board-level
`
`implementation.
`
`[0044]
`
`Figure 29(a) and (b) shows one embodiment of a software acceleration
`
`architecture.
`
`Detailed Description
`
`[0045]
`
`Figure 1 shows layers of an embedded security protocol system 100. At the
`
`highest level, the system 100 includes a protocol layer 101 that provides confidentiality and
`
`identify verification. An algorithm layer 102 is provided below the protocol layer 101. The
`
`algorithm layer 101 includes one or more algorithms, such as, for example, encryption
`
`algorithms (e. g., Kasumi, Rijndael, RC4, MDS, etc.), used by the protocol layer 101. In the
`
`present disclosure,
`
`the Rijndael algorithm is used by way of example of an encryption
`
`algorithm, and not by way of limitation. An architecture layer 103 is provided below the
`
`algorithm layer 102.
`
`In one embodiment,
`
`the architecture layer 103 includes a virtual
`
`machine, such as, for example, a JAVA virtual machine. A micro-architecture layer 104 is
`
`provided below the architecture layer 103. In one embodiment, the micro-architecture layer
`
`104 includes one or more processor architectures. A circuit layer 105 is provided below the
`
`micro—architecture layer 104.
`
`[0046]
`
`As security is only as strong as the weakest link, a breech in any of the
`
`abstraction layers 101-105 can compromise the entire security model. Hence design of the
`
`secure embedded system is based on a top-down design flow and security scrutiny at each
`
`abstraction level.
`
`[0047]
`
`Figure 2 shows a thumbpod 200 as an embodiment of a device that is
`
`based on the security pyramid shown in Figure 1. The thumbpod 200,
`
`is configured as a
`
`keychain-type device that includes a biometric sensor 202, a communication port 204, and
`
`embedded hardware components. The sensor 202 obtains biometric identification data (e.g.,
`
`fingerprint identification data, voice identification data, retina identification data, genetic
`
`

`

`WO 2005/001751
`
`PCT/U52004/017545
`
`identification data, etc.) from a user.
`
`In an alternative embodiment,
`
`the thumbpod 200 V
`
`includes a sensor 202 for obtaining identification data from a user, such as, for example,
`
`biometric identification data, password data, PIN data, Radio Frequency Identification Tag
`
`(RFID) data, etc.
`
`In one embodiment,
`
`the sensor 202 is a fingerprint sensor.
`
`In one
`
`embodiment, the sensor is an imaging device. In one embodiment, the sensor 202 includes a
`
`CMOS imaging device. A fingerprint device is used herein by way of example, and not by
`
`way of limitation.
`
`[0048]
`
`The communication port 204 can include a wireless port and/or a wired
`
`port to provide flexible communication. In one embodiment, the port 204 includes a wireless
`
`port, such as, for example, an infrared port, a radio-frequency port, an inductive coupling
`
`port, a capacitive coupling port, a Bluetooth port, a wireless Ethernet port, etc. In one
`
`embodiment, the port 204 includes a wired port, such as, for example, a USB port, a firewire
`
`port, a serial port, an Ethernet port, a PCMCIA port, a flash memory port, etc.
`
`[0049]
`
`The thumbpod 200 is configured to be used in connection with a security
`
`protocol (as described in connection with Figures 3 and 4 to provide safe use of biometric
`
`sensor data. The biometric data does not leave the thumbpod 200 but it
`
`is used with a split-
`
`key generation function to protect the data. The thumbpod 200 provides a verifiable bond
`
`between a user and the thumbpod 200 based on biometric sensor data. The thumbpod can be
`
`used for a wide variety of authentication—related transactions, such as, for example, wireless
`
`credit card payments, keychain flash memory replacement, universal key functionality
`
`(house, car, office), storage of sensitive medical data, IR secure printing, etc.
`
`[0050]
`
`The thumbpod 200 uses biometrics to bind a user to an identification code,
`
`such as, for example, an account number, an access code, a password, an the like (hereinafter
`
`referred to generically as an account number). At each transaction, the user’s biometric data
`
`(e.g., fingerprint) is used to digitally sign a transaction as proof of identification. This
`
`fingerprint
`
`is digitally verified by an authentication server. The protocol used by the
`
`thumbpod and the authentication server ensure that sensitive biometric data is not transmitted
`
`

`

`WO 2005/001751
`
`PCT/U52004/017545
`
`freely, particularly across wireless or other insecure channels. The protocol described below
`
`provides an authentication scheme in which no actual biometric data is transmitted and no
`
`biometric data is stored at
`
`the server. Rather, biometric information is captured in the
`
`thumbpod 200 and used to generate a key K (which is stored at the authentication server) for
`
`symmetric—key encryption. This key is used to encrypt challenge and response functions,
`
`based on a random number, which are in turn transmitted across the wireless channel.
`
`[0051]
`
`Figure 3A is a block diagram of an authentication protocol 300 that uses a
`
`relatively strong one—way authentication protocol between an authentication server 310 and
`
`an authentication device 311, and a relatively week security protocol between and the device
`
`311 and a user 303, as is currently used in traditional credit card authorization systems. In the
`
`traditional credit card authentication scheme, a server authenticates merely with a physical
`
`credit card (or more specifically, with an account number stored on a magnetic strip of a
`
`credit card). In an e-commerce scenario, a physical card is not required—an account number
`
`and expiration date are sufficient. The traditional schemes provide a two—fold authentication:
`
`1) the server authenticates the credit device, and 2) the server (nominally) authenticates the
`
`ownership of the card. A significant problem with the current credit card-type transaction
`
`protocols is the weak authentication tie between the user and the transaction device (the
`
`credit card). It is often the case that in brick—and-mortar commerce, proof of authentication is
`
`not required. In ATM transactions, a personal identification number (PIN) may tie a user to
`
`the card. However, PIN numbers do not provide high levels of security. PIN number are often
`
`easily broken or repetitive numbers, written on the back of cards, forgotten, etc.
`
`[0052]
`
`Figure 3B is a high-level block diagram of an authentication protocol 301
`
`used in connection with the thumbpod 200. The authentication protocol 301 uses a relatively
`
`strong two-way authentication protocol between the authentication server 310 and the
`
`authentication device (e. g., the thumbpod 200), and a relatively strong authentication protocol
`
`(e.g., biometric authentication) between and the thumbpod 200 and the user 303.
`
`

`

`WO 2005/001751
`
`PCT/U52004/017545
`
`[0053]
`
`The protocol 301 is an example of a complex application in which
`
`thumbpod 200 uses both cryptographic and signal processing functionality. There are various
`
`other protocols for other applications for the thumbpod 200 that share one or both of the
`
`common denominators of cryptography and biometric signal processing. Other applications
`
`include encryption/decryption and/or verification for audio and video systems.
`
`[0054]
`
`Figure 4 shows an example system 400 that uses the authentication
`
`protocol 301 and a flow diagram of the authentication protocol 301. The system 400 includes
`
`the thumbpod 200, a merchant’s transaction register 401, and the authentication server 310.
`
`The authentication protocol 301 can be used in connection with a brick-and-mortar pay—point
`
`transaction, an e-commerce transaction, a computer 10 gin transaction, or any other transaction
`
`the requires authentication.
`
`[0055]
`
`In the protocol 301, the thumbpod 200 sends an account number to the
`
`transaction register 401. The transaction register 401 then sends the account number and data
`
`regarding the transaction (e.g., a transaction dollar amount), to the server 310. The transaction
`
`register 401 and the server 310 provide mutual authentication through standard protocols,
`
`such as, for example, the SET protocol. The server 310 uses the account number to look up
`
`the identity of the thumbpod 200 and to obtain a secret key known to the thumbpod 200. The
`
`server 310 generates a first authentication vector and encrypts the first authentication vector
`
`using the secret key. The encrypted first authentication vector is then sent to the transaction
`
`register 40]. The transaction register forwards the first authentication vector to the thumbpod
`
`200. The thumbpod 200 decrypts the first authentication vector and verifies the identity of the
`
`authentication server 310. The thumbpod also authenticates the user and generates a second
`
`authentication vector. The second authentication vector is encrypted using the secret key. The
`
`thumbpod 200 returns the authentication vector to the transaction register 401, which
`
`forwards the second authentication vector to the authentication server 310. The authentication
`
`server 310 decrypts the second authentication vector and verifies the identity of the thumbpod
`
`200. Once the identity of the thumbpod has been verified, the authentication server 310 sends
`
`a “transaction complete” message to the transaction register 401. The transaction forwards
`
`-10-
`
`

`

`WO 2005/001751
`
`PCT/US2004/017545
`
`the transaction complete message to the thumbpod 200, which then increments a transaction
`
`counter. In one embodiment, streaming encryption is provided between the thumbpod 200,
`
`the transaction register 401 , and/or the server 310.
`
`[0056]
`
`In order to make a transaction at the transaction register 401, the user 303
`
`uses the thumbpod wireless port 204 to initiate communication with the register. Challenge
`
`and response functions are negotiated between the user 303 and the server 310, routed
`
`through the merchant’s register 410 (which cannot interpret the data because it does not
`
`posses secret keys known to the thumbpod 200 and the server 310). In the course of the
`
`authentication protocol, the user 303 places his/her finger on the fingerprint sensor 202 to
`
`provide identity verification. This information is processed within the thumbpod 200 and, if a
`
`match is made, cryptographic hash functions and keys are generated using encryption
`
`algorithms and the protocol continues to its completion.
`
`[0057]
`
`In the protocol 301,
`
`three items are used for valid authentication
`
`transactions: 1) the account number stored in the thumbpod 200, 2) the thumbpod 200 itself
`
`(which generates the secret key K), and 3) the correct biometric component (e.g., a finger, a
`
`retina, etc.) for live—scan sensing by the sensor 202. These three elements provide a strong tie
`
`between the user 310 and the thumbpod 200 account number. In an e-commerce situation,
`
`merely having a stolen account number (and expiration date) would be insufficient to make a
`
`transaction. Likewise, an account number and a stolen thumbpod 200 are also insufficient.
`
`All three components are required to make a valid transaction.
`
`[0058]
`
`In the protocol 301 a threefold-authentication takes place: 1) the server
`
`310 authenticates the thumbpod 200, 2) the thumbpod 200 authenticates the server 310 (and
`
`transaction register 410), and 3) the thumbpod 200 authenticates the user 310. Unlike
`
`traditional schemes, the user 303 authenticates the server and the transaction register 401,
`
`providing protection against fraudulent or malicious merchants. Hence, the protocol retains
`
`the advantages of the current credit card-type protocols, while supplementing the protocols
`
`with stronger security, transaction device-to-user binding, and authentication directionality.
`
`-11-
`
`

`

`W0 2005/001751
`
`PCT/U52004/017545
`
`Other advantages of the protocol 301 include fraud detection as well as authentication at each
`
`transaction.
`
`[0059]
`
`As shown in Figure 4,
`
`the thumbpod 200 begins the transaction by
`
`transmitting the user’s account identification to the merchant’s transaction register 401. The
`
`transaction register 401 authenticates with the authentication server using conventional
`
`protocols. Note that the protocol 301 need not replace current protocols. Rather, the protocol
`
`301 supplements the current protocols with an additional
`
`layer of encryption—based
`
`authentication. The transaction register 401 transmits the account number and the transaction
`
`amount to the authentication server 310.
`
`[0060]
`
`The server 310 begins its side of the authentication process by loading the
`
`user’s secret key K, which is shared only between the server 310 and the thumbpod 200. In
`
`one embodiment, the secret key is at least 128 bits. The server 310 also loads a user’s counter
`
`value SQNAS and an institution authentication parameter AMF. In one embodiment,
`
`the
`
`counter value SQNAs-is at least 48 bits, and the institution authentication parameter AMF is
`
`at least a 16 bits. The counter value SQNAS is stored both on the server and on the thumbpod
`
`200 and is used to prevent replay attacks. The server 310 loads and encrypts an operator code
`
`OP, producing OPc (which can be optionally pre—stored). In one embodiment, the operator
`
`code OP is at least 128 bits. Finally, the server 310 generates a random value RAND and uses
`
`K with Rijndacl primitives to generate a set of authentication parameters for the specific
`
`transaction. In one embodiment, RAND is at least 128 bits. The authentication parameters
`
`include:
`
`o MACAS:
`
`a message authentication code of the server to prove its identity to the
`
`thumbpod 200 (in one embodiment, the MACAS is at least 64-bits).
`
`o XRESAS: an expected response of the thumbpod 200 to prove its identity to the
`
`server (in one embodiment, XRESAS is at least 64 bits).
`
`0 AK: an anonymity key to mask the counter value CTRAS for transmission (in one
`
`embodiment, AK is at least 48 bits).
`
`-12-
`
`

`

`W0 2005/001751
`
`PCT/U52004/017545
`
`0 CK (optional): a cipher key to allow for streaming encryption after authentication
`
`is performed (in one embodiment, CK is at least 128 bits).
`
`0
`
`lK(optional): an integrity key allowing for data integrity and origin authentication
`
`of streaming encryption data (in one embodiment, [K is at least 128 bits).
`
`[006]]
`
`After the above authentication parameters are generated, the server 310
`
`transmits a subset of the authentication parameters—the authentication vector—to the
`
`transaction register, which forwards the vector to the Thumbpod 200. The authentication
`
`vector includes:
`
`- RAND;
`
`0
`
`SQNAS : the counter value of the server masked by the anonymity key;
`
`0 AMP: the institution authentication parameter; and
`
`o MACAS: the message authentication code of the server to prove its identity to the
`
`thumbpod 200.
`
`[0062]
`
`As in 3GPP authentication, the authentication between the thumbpod 200
`
`and the server 310 is a mutual authentication based on the shared secret key K. The random
`
`session value RAND is coupled with K to provide the two primary challenge/response
`
`vectors: MACAS and RESTP. The MACAS vector proves the identity of the server 310 to the
`
`thumbpod 200. Only the server 310 with the precise value of K (and the current random
`
`session value RAND) will be able to produce the proper MACAs. When the thumbpod 200
`
`verifies this value by comparison with its generated expected value of XMAC-rp (based on K
`
`and RAND) it determines whether the proper key K was used, and hence whether the server
`
`310 is genuine. The same argument holds for the RES-n) vector, which is used to verify the
`
`identity of the thumbpod 200 to the server by comparison with XRESAS. When both
`
`challenge/response values are verified, then mutual authentication is assured. The random
`
`number RAND and the sequence number SQNTp/AS are used to prevent replay attacks on
`
`previously-used authentication vectors obtained through eavesdropping on the channel. Since
`
`the sequence number follows a deterministic pattern (bit increment at each transaction), it is
`
`-13-
`
`

`

`WO 2005/001751
`
`PCT/US2004/017545
`
`masked by a one—use anonymity key AK as it is transmitted over the channel to prevent smart
`
`replay attacks.
`
`[0063]
`
`At
`
`this point,
`
`the protocol 301 enters into a biometric authentication
`
`portion which differs from 3GPP or other wireless authentication protocols. The thumbpod
`
`200 stores the authentication vector and begins biometric authentication by requesting that
`
`the user 303 to provide biometric data (e.g., place his/her finger on the fingerprint sensor
`
`202). The Thumbpod 200 performs imaging, feature extraction, matching, and decision.
`
`During imaging, the thumbpod 200 images fingerprint to produce a bitmap of raw data. In
`
`one embodiment, the bitmap is at least 128 x 128 8-bit grayscale. During feature extraction,
`
`the thumbpod 200 processes the raw data, enhances the image, and extracts the minutiae
`
`types (ridges, bifurcations) and locations of the candidate fingerprint. During the matching
`
`process, the thumbpod 200 loads a stored fingerprint template and performs a matching
`
`function to produce a match score. During the decision process, the thumbpod 200, using the
`
`match score, decides if the candidate fingerprint is a match to the template.
`
`[0064]
`
`If the algorithm detects an incorrect match, an error vector is transmitted to
`
`the server 310 and the protocol 301 is terminated. If the algorithm detects a match, the
`
`authentication protocol 301 continues. Using Rijndael in CBC-MAC mode, the shared secret
`
`key K is created by hashing the fingerprint template using a pre—stored 128-b key generator
`
`value KG according to K = HASHKG(temp1ate). (Alternatively, the value of K can also be
`
`pre—stored in the embedded device.)
`
`[0065]
`
`In one embodiment, after loading the received values of RAND and AMF,
`
`the thumbpod 200 loads OP and uses the secret key K and Rijndael primitives to generate:
`
`o OPC: an encrypted operator code (optionally pre-stored). In one embodiment OPC
`
`is at least 128-bits.
`
`0 AK: an anonymity key to unmask the counter value CTRAS. In one embodiment
`
`AK is at least 128 bits.
`
`-14-
`
`

`

`W0 2005/001751
`
`PCT/U52004/017545
`
`0
`
`CTRAS: a counter value of the server. In one embodiment CTRAS is at least 48
`bits.
`
`0 XMACTP: an expected message authentication code of the server to prove its
`
`identity to the thumbpod 200. In one embodiment XMACTp is at least 64 bits.
`
`- RESTP: a response of the Thumbpod 200 to prove its identity to the server. In one
`
`embodiment RESTP is at least 64 bits.
`
`0 CK (optional): a cipher key to allow for streaming encryption after authentication
`
`is performed. In one embodiment CK is at least 128 bits.
`
`0
`
`IK (optional): an integrity key to