Biometric non-repudiation network security systems and methods

[0001] This invention relates generally to electronic transactions over a network, and more particularly to security systems and methods for biometrically verifying a transaction author.

[0002] Currently, the most widely used internet secure protocol does not have a mechanism to address a possible denial of validity, or repudiation, of an act such as an on-line purchase by a user. The term repudiation includes rejecting, disowning, or disclaiming as invalid a particular act or operation purportedly executed by a particular user or person. For example, a user can claim that his credit card was stolen and falsely charged, resulting in significant financial losses each year. Even the popular HyperText Transfer Protocol with Secure Sockets Layer (HTTPS) fails to provide un-falsifiable evidence that a specific action occurred. Therefore, there remains a need in the art for devices and methods that address problems due to the lack of a non-repudiation security mechanism.

[0003] FIG. 1 shows a network with interconnections between a client, a file server and a public key server, in accordance with an embodiment of the present invention.

[0004] FIG. 2 shows a block diagram view of a client device and a file server, in accordance with an embodiment of the present invention.

[0005] FIG. 3 shows a block diagram view of a biometric non-repudiation security flow, in accordance with an embodiment of the present invention.

[0006] FIG. 4 shows a block diagram view of a flow to establish a client key pair and a biometric key pair, in accordance with an embodiment of the present invention.

[0007] FIG. 5 shows a block diagram view of a flow wherein a file server responds to a transaction request and asserts a user biometric challenge, in accordance with an embodiment of the present invention.

[0008] FIG. 6 shows a block diagram of a flow wherein a user responds to a biometric challenge with a biometric authentication, in accordance with an embodiment of the present invention.

[0009] FIG. 7 shows an exemplary embodiment of an encrypted, authenticated transaction request, in accordance with an embodiment of the present invention.

[0010] FIG. 8 shows a block diagram of a flow wherein the file server authenticates the transaction request and processes the transaction, in accordance with an embodiment of the present invention.

[0011] FIG. 9 shows a block diagram view of a client device interfacing with an external biosensor and two user terminals, in accordance with an embodiment of the present invention.

[0012] FIG. 10 shows a block diagram view of a client device disposed within a user terminal that includes a biometric unit with an internal biosensor, in accordance with an embodiment of the present invention.

[0013] Embodiments of the present invention and their advantages are best understood by referring to the detailed description that follows. It should be appreciated that like reference numerals are used to identify like elements illustrated in the figures.

[0014] Devices, methods and systems are disclosed herein, in accordance with one or more embodiments of the present invention, that provide a very strong security mechanism by using a unique identification pairing of a client device's serial number and a user's own biometric information. The devices and methods may also be effective in reducing the repudiation incidence for particular acts, such as on-line purchases, under certain conditions.

[0015] A client-server system can include a server device in a preferred location and a plurality of client devices that are distributed to users in a traditional client/server arrangement. Depending on the type of service, the client devices can include television set-top boxes such as cable decoders, internet enabled phones, cellular phones, personal computers (PCs), personal digital assistants (PDAs), embedded system devices, and network devices, for example. Each client device has a unique client identifier that is associated with a client device public key cryptosystem key pair. The client device also has a biometric, such as a fingerprint reader, that can produce a biometric feature based on a biometric sample.

[0016] FIG. 1 shows an exemplary network 100 with interconnections between a client device 102, a file server 104, and a public key server 106. Client 102, file server 104, and public key server 106 can send and receive messages over a traditional interconnection network 108, such as a switched packet network including the Internet, or another network or sub-network conforming the Internet Protocol (IP) and/or the Transfer Control Protocol (TCP). Client 102 is connected to network 108 through a communication channel 110, file server 104 is connected to network 108 through communication channel 112, and public key server 106 is connected to network 108 through a communication channel 114 so that information may be exchanged between the network devices (102, 104, 106) through network 108. Each communication channel (110, 112, and 114) can be a wired or wireless connection for sending and receiving messages between these and other network devices connected to network 108. In this exemplary network 100, client 102 may request a transaction with file server 104 that is facilitated using public keys stored in public key server 106 that functions as a public trusted center or key escrow repository.

[0017] FIG. 2 shows a block diagram view of client 102 and file server 104 connected by network interconnections (110, 112). Client 102 includes a processor 202, a processor memory 204, a biometric unit 206, a client device identifier 208, a network transceiver unit 210, a cryptographic engine 212, and a tamper resistant memory 214. Processor 202 can be a suitably programmed microprocessor for use in controlling the operations of client 102 as well as the sending and receiving of messages through transceiver unit 210 over communication channel 110. Processor memory 204 can store and retrieve data including a server public key 220 corresponding to file server 104 and other information for both temporary and long-term storage.

[0018] Processor memory 204 can be any conventional memory storage device including a Random Access Memory (RAM), a magnetic or optical disc, or a register file implemented on a computer chip, for example.

[0019] Biometric unit 206 includes a biometric sensor (FIGS. 9 and 10) for sensing a portion of a body, such as a digit or an eye, to determine a biometric feature based on the sensed body portion. Client device identifier 208 can be a serial number or other identification that is unique 20 to client 102. Cryptographic engine 212 can execute one or more cryptographic algorithms to encrypt and decrypt message data, generate cryptographic keys, and generate cryptographic signatures based on the defined parameters of one or more cryptographic algorithms. Tamper resistant memory 214 can store and retrieve a client private key 222, a client public key 224, a user biometric feature 226, a user biometric private key 228 and a user biometric public key 230.

[0020] Exemplary cryptographic algorithms for execution within cryptographic engine 212 can include a public-key encryption and decryption algorithm such as the ubiquitous RSA (Rivest, Shamir, and Adleman) algorithm by RSA Security of Bedford, Mass. The Internet Engineering Task Force (IETF) Request For Comments (RFC) document number 2313, referred to as IETF-RFC2313, describes the RSA public-key cryptosystem. Another cryptographic algorithm family is the Secure Hash Algorithm (SHA), referred to in another IETF document IEFT-RFC3174, that provides for computing a unique “fingerprint” of a message. A third cryptographic algorithm, the Digital Signature Standard (DSS), utilizes SHA-1 computes a digital signature to uniquely identify a particular user as the author of a particular message. DSS, as described in the U.S. Federal Information Processing Standards Publication 186 referred to as FIPS 186, provides a Digital Signature Algorithm (DSA) standard for generating a digital signature.

[0021] Since memory 214 stores sensitive information, it is constructed in a way that it is physically secure and cannot be easily tampered with. That is, memory 214 can, for example, contain sensors in order to detect or reveal when the memory outer casing is violated, packaging the memory device so it is not easily accessible, utilizing built-in circuitry to provide translation of the input or output data or to unlock the memory contents, and/or using an error correction method to yield a proper output, and other techniques. Tamper resistant memory 214 can be considered as an identity memory since the identifying information for the client and one or more particular users can be stored within. A number of users may be associated with a particular client device 102. Hence, tamper resistant memory 214 may include a number of user data sets, each including a user biometric feature 226, a biometric private key 228, and a biometric public key 230. Finally, memory 214 can be removable so that the client identification and user identifying information may be transferred to another client in the event that a failure occurs in client 102 or if maintenance is required for client 102.

[0022] One or more client biometric features 226 may be stored in memory 214 corresponding to a number of users associated with client 102. Client private key 222 and client public key 224 comprise a public-key cryptographic system key pair associated with client 102 and stored with or identified with client device identifier 208 so that a public user may encrypt a message to the client device by using the associated public key. The public key of a key pair is generally widely available and may be used by a second network device to encrypt a message with a public key so that only the party in possession of the associated private key may successfully decrypt and read the message. Similarly, biometric private key 228 and biometric public key 230 comprise another key pair for use with a public key cryptographic algorithm where the biometric key pair is associated with a particular user. This association with a particular user can include association such as with any one of a particular user account, an e-mail account, or another user identifier. Alternatively, a public key may be used to encrypt or encipher a message so that the corresponding private key is needed to decrypt or decipher the message. The client identifier can be associated with a client public key and/or the client public key may be used as a client identifier. It may be preferable in some applications to associate a predetermined client identifier with a subsequently generated client public key in order to conform to a client identifier pattern such as a sequential order.

[0023] File server 104 can be a network device that can respond to transaction requests such a request to create a new record of information, view an existing record, change an existing record, or delete a record. Changing records in this manner may be associated with an on-line purchase using a credit card, provisioning service from an online service provider, or other transaction related to Internet-based commerce.

[0024] While a regular username and user password may be sufficient for non-critical access, due to security concerns, only authorized users may execute transactions for particular records. For a network device with access to the Internet 108, as shown in FIG. 1, physical security is not usually sufficient to safeguard access to a network device. Hence, there is a need to authenticate a user prior to granting a requested transaction. File server 104 includes a processor 240, a processor memory 242, a network transceiver unit 244, a cryptographic engine 246, a tamper resistant memory 248, and a file server record unit 250. Processor 240 can be a suitably programmed microprocessor for use in controlling the operations of file server 104 as well as the sending and receiving of messages through transceiver unit 244 over communication channel 112. Processor memory 242 can store and retrieve data including a client public key 260, a biometric public key 262 for a user at client 102, and a validation token data 264, along with other information for both temporary and long-term storage. Processor memory 242 can be any conventional memory storage device including a Random Access Memory (RAM), a magnetic or optical disc, or a register file implemented on a computer chip, for example.

[0025] Cryptographic engine 246 can execute one or more cryptographic algorithms to encrypt or decrypt message data, generate cryptographic keys, and generate cryptographic signatures corresponding to algorithms executed by cryptographic engine 212, as previously discussed. Tamper resistant memory 248 can store and retrieve a server private key 266. Finally, file server record unit 250 can include a number of data records, shown as Record-1 268 through Record-N 270. In an exemplary operation, a user associated with client 102 may request a transaction using record-1 268, where file server 104 can authenticate both the identity of the requesting user as well as the purported client device 102 through which the request was made. In this manner, both the identity of a user and the expected location of the user's access can be verified prior to granting access to a requested record.

[0026] FIG. 3 shows a block diagram view of a biometric non-repudiation security flow 300 to authenticate a user's identity and location in order to avoid a later disavowal of the user-initiated transaction. Beginning at start 302, flow 300 begins with establishing 304 a client device public and private key pair for client 102, as described in reference to FIG. 1. Once the client device key pair is established, flow 300 continues with establishing 306 a user biometric key pair to define a public and private key pair associated with a particular user at client 102 including the generation of a golden biometric sample of a user. Once both the client key pair and the user biometric key pairs are established, flow 300 continues with the user asserting 308 a transaction request to file server 104, as described in reference to FIG. 1.

[0027] Flow 300 continues with the file server responding to the transaction request by asserting 310 a user biometric challenge followed by the user responding 312 to the biometric challenge with a biometric authentication including a new biometric sample. The new biometric sample is compared with the golden biometric sample collected previously and will either match or fail to match in operation 312. If the biometric fails to match, flow 300 will terminate with the biometric failing 314. However, if the biometric matches, flow 300 will continue with authenticating 316 the transaction request and processing the requested transaction. The authentication of the transaction request in operation 316 will either pass or fail. If the authentication fails, flow 300 will terminate with the authentication failing 318. However, if the authentication passes, the requested transaction is processed and flow 300 terminates successfully at end 320.

[0028] FIG. 4 shows a block diagram view of a flow comprising operation 304 for establishing a client key pair and a flow comprising operation 306 for establishing a biometric key pair in flow 300, as discussed in reference to FIG. 3. Operation 304 includes a first decision 402 to determine whether the client key pair is already defined. If a client key pair is not already defined, the decision of 402 is “N” and operation 304 then includes the operations of generating 404 a client key pair associated with the client device identifier, sorting 406 the client key pair in the tamper resistant memory, and publishing 408 the client public key with key server 106, as shown in FIG. 1. Conversely, if the client key pair is already defined, the decision of 402 is “Y” and the key pair may have been loaded onto a new client 102 with the public key already published in the corresponding key server, for example. In this case, flow 300 continues directly to establishing 306 the biometric key pair in operation 306. Alternatively, a client key pair may be defined, stored in the tamper resistant memory, yet not published in the corresponding key server. In this case, the flow comprising operation 304 is abbreviated to only include publishing the client public key with the corresponding key server. The process of publishing a public key includes sending one or more messages to the corresponding key server enclosing the public key and an identifier for client 102 that may include the client identifier 208, as discussed in reference to FIG. 2.

[0029] A flow comprising operation 306 for establishing a biometric key pair includes activating 410 a biometric sensor (FIGS. 9 and 10) associated with biometric unit 206, as mentioned in reference to FIG. 2. The biometric sensor generates 412 a golden biometric feature determined by scanning a portion of a user's body, such as the fingerprint or an iris, in order to extract information useful in uniquely identifying the scanned portion of the user's body. The flow of operation 306 continues with generating 414 a biometric key pair associated with the golden biometric feature. There is a unique, one-to-one association between the biometric feature and the biometric private key. Neither the biometric feature nor the biometric private key is to be published during the registration of an authorized user with the client device. No one can change the biometric private key or the biometric feature of the authorized user once the registration of that authorized user is complete. After the user biometric key pair is generated, the flow of operation 306 continues with publishing 416 the biometric public key with the key server 106. Once both the golden biometric feature and biometric key pair are generated, operation 306 ends with storing 416 the user biometric feature 226, biometric private key 228, and biometric public key 230 into tamper resistant memory 214, as discussed in reference to FIG. 2.

[0030] FIG. 5 shows a block diagram view of a flow comprising operation 310 for responding to the transaction request by asserting a user biometric challenge in flow 300, as discussed in reference to FIG. 3. Operation 310 includes the file server receiving the transaction request from a user at client device 102 and determining 502 a biometric authentication is required. This determination can be made based on several factors, including the nature of the requested transaction itself, a limitation of classification of the requested transaction or data, and the location of client 102 or the identity of the user/requestor. Operation 310 continues with the file server retrieving 504 the associated client public key from key server 106. After retrieving the client public key, operation 310 continues with the file server generating 506 and storing a biometric challenge message containing random token data. This random token data is used later to validate a received message since only the file server originally possesses the random token data. Operation 310 continues with the file server encrypting 508 the challenge message using the retrieved client public key, and the file server sending 510 the encrypted challenge message to the requesting user at client 102. File server may send the message of operation 510 to the authenticated address of client 102, rather than a purported address in a particular recent transaction in order to guard against falsification of this message.

[0031] FIG. 6 shows a block diagram of a flow comprising operation 312, wherein a user responds to a biometric challenge with a biometric authentication in flow 300, as discussed in reference to FIG. 3. A flow comprising operation 312 includes the user at the client device receiving 602 the encrypted challenge message, and decrypting 604 the challenge message using the client private key 222. This ensures the user is actually connected with client 102, since only client 102 is in possession of client private key 222. Once the challenge message is decrypted, operation 312 continues with the client device extracting 606 the token data from the challenge message. Once the token data is extracted, flow 312 continues with the user at client 102 generating 608 a session biometric sample from which is extracted a session biometric feature in a manner similar to the user biometric feature 226. The user will be prompted to provide the biometric sample by interacting with the biometric sensor.

[0032] Operation 312 continues with comparing 610 the session biometric feature with the golden biometric feature 226. When the session and golden biometric features do not match, the decision 612 is “N” and the biometric fails 314. However, when the session and golden biometric features match, the decision 612 is “Y” and the operation 312 continues with generating 614 a hash of the extracted token data. A hash is generated to reduce overall message size. The hashing algorithm must be known and agreed upon by both client 102 and file server 104. Once the hash is generated, operation 312 continues with signing 616 a hash of the token data with biometric private key 228, and appending 618 the signed hash to the transaction request to generate an authenticated transaction request. Operation 312 continues with encrypting 620 the authenticated transaction request with the file server public key 220, and sending 622 the encrypted transaction request to file server 104. In this manner, the authenticate transaction request includes a message that is encrypted with the file server public key so that only the file server may decrypt the message. This ensures that the requested transaction is secured, and will not be meaningful to any device not in possession of the corresponding server private key 266.

[0033] FIG. 7 shows an exemplary embodiment of an encrypted transaction request 700 as described in operation 312, as shown in FIG. 6. Request 700 employs a layered encryption protocol to ensure that only an authenticated transaction request may be successfully received and processed. A transaction request 702 and a token data hash 704 encrypted with the user biometric private key together comprise an authenticated transaction request 706 that is then encrypted by the server public key.

[0034] FIG. 8 shows a block diagram of a flow comprising operation 316, wherein the file server authenticates the transaction request and processes the transaction in flow 300, as discussed in reference to FIG. 3. A flow comprising operation 316 includes the file server receiving 802 the encrypted authenticated transaction request, decrypting 804 the encrypted authenticated transaction request using server private key 266, and extracting 806 and encrypted hash of the token data. Operation 316 continues with file server 104 retrieving 808 biometric public key 230 from key server 106, and decrypting 810 the encrypted hash of the token data using biometric public key 230 to form a received token hash. Operation 316 continues with computing 814 a hash of the stored token data in file server 104, and comparing 816 the decrypted hash to the extracted hash in operation 810. If the hash values do not match, the decision 818 is “N” and authentication fails 318. However, if the hash values match, then the decision 818 is “Y” and operation 316 continues with processing 820 the transaction request, and flow 300 successfully terminates at end 320.

[0035] In this manner, an authenticated user has executed a transaction in a client/server environment which is non-repudiatable since they cannot later disavow either transaction or their identify as the transaction author. Since the session biometric is compared in real-time to the golden biometric at the time of the transaction, the key server has provided the appropriate public keys, and the file server communicates with the client based on the client identifier, the presence of the user at the client 102 is verified along with the biometric signature. The authorship of the transaction by the user cannot be disputed.

[0036] FIG. 9 shows a block diagram view of a client device 102 interfacing with an external biosensor 902 (finger scanner) and two user terminals (904, 906) where external biosensor 902 is external to the body of client 102. External biosensor 902 is configured to determine a biometric feature, such as the distinguishing components of a finger print image, from a user's finger 908 placed on a finger-reading portion 910 of external biosensor 902 where the biometric feature is communicated to biometric unit 206 through a communications channel 912 and communicated to client 102 and then stored in a memory. User terminal #1 904 is connected to client 102 through a communications channel 914, while user terminal #2 906 is connected to client 102 through a communications channel 916. Each of the communication channels (912, 914, and 916) can be a wireless radio connection, a wireless optical connection, or a wired connection such as a network cable. In this embodiment, client device 102 can be a router or other customer premises equipment (CPE) for connecting one or more user terminals on a local area network (LAN) 918 at a first level of network hierarchy to a wide area network (WAN) 920 at a second level of network hierarchy. User terminals (904, 906) can be any network device including a personal computer (PC), a network enabled telephone, a personal digital assistant (PDA), a set-top cable decoder box, or game console, for example. External biosensor 902 may be moved to a position near either user terminal #1 or #2 (904, 906) so that a user operating either of these terminals may exercise the biometric non-repudiation security flow 300, as described in reference to FIG. 3. External biosensor 902 may be incorporated into a hand-held sensing device or into the outer covering of another device such as a smart card, or dongle.

[0037] FIG. 10 shows a block diagram view of a client device 102 disposed within a user terminal 1002 that includes a biometric unit 206 with an internal biosensor 1004 (eye scanner), where biosensor 1004 is internal to the body of client 102. Internal biosensor 1004 is configured to determine a biometric feature, such as an iris or retina print, from a user's eye 1006 where the biometric feature is communicated to client 102 and stored in a memory. In this embodiment, user terminal 1002 can be a computer connected to a network 110 or other similar network, while client 102 includes a built-in biosensor 1004 which can be mounted on a monitor device or stalk (not shown) for conveniently scanning a user's eye. In this manner, user terminal 1002 can be considered a biometric authentication terminal where one or more users may exercise the biometric non-repudiation security flow 300, as described in reference to FIG. 3.

[0038] Although the invention has been described with respect to particular embodiments, this description is only an example of the invention's application and should not be taken as a limitation. Consequently, the scope of the invention is set forth in the following claims.