GB2434724A

GB2434724A - Secure transactions using authentication tokens based on a device "fingerprint" derived from its physical parameters

Info

Publication number: GB2434724A
Application number: GB0600699A
Authority: GB
Inventors: Yurong Lin
Original assignee: DEEPNET TECHNOLOGIES Ltd
Current assignee: DEEPNET TECHNOLOGIES Ltd
Priority date: 2006-01-13
Filing date: 2006-01-13
Publication date: 2007-08-01
Also published as: GB0600699D0

Abstract

The invention provides methods and systems for authenticating the parties to a transaction over a network. The first party sends a first authentication token to the second party. The second party sends a second authentication token to the first party. The first party verifies the second token and the second party verifies the first token. The transaction proceeds if both tokens are successfully verified. In accordance with the invention, at least one of the authentication tokens comprises or is based on a device "fingerprint" of the device from which it is sent. The fingerprint is a unique identifier for the device and is based on one or more of the device's physical properties or parameters, e.g. memory space, CPU serial number. A hash function of the selected properties may be used (e.g. MAC). A registration phase is initially performed, if the two parties are a customer and a server, including the use of passwords and activation codes. One of the parties may use a certificate for authentication instead of the fingerprint. Subsequent messages between the parties, are encrypted with a session key provided by one of the parties e.g. its public key, which is also used to sign the authentication transaction.

Description

1 2434724 Secure Transactions

Field of the Invention

The present invention relates to methods and systems for enabling transactions between parties over a communications network to be effected in a secure manner. More specifically, it is concerned with methods and systems for authenticating parties to the transaction. The invention is particularly suited to authenticating parties communicating over a public network such as the Internet.

Background

An increasing number of personal and business transactions are being carried out over the Internet. The Internet is a very efficient mechanism for communication between parties to a transaction but suffers from the draw back that there is potentially a great deal of uncertainty as to the authenticity of the parties to the transaction. Typically the parties to a transaction will be a user (private or business) on the one hand and a server associated with a commercial organisation (e g. a financial institution or online commerce website) on the other hand. The user interacts with one or more automated services running on the server to complete a transaction Phishing attacks, i e. fraudulently acquiring sensitive information (e.g. credit card details) by luring users to spoofed websites, and other such Internet frauds are becoming an increasing problem in society today. As a consequence there is a growing need for effective and easy to implement approaches for authenticating the identity of parties to a transaction carried out over the Internet (or other communications I computer network) and subsequently ensuring the security of messages passed between the authenticated parties.

The most common approach for Server authentication, that is the server confirming its identity to the user, is to use certificate based (especially PKI -Public Key Infrastructure -certificate) authentication. A PKI infrastructure provides for trusted third-party vetting of and vouching for the identities of parties (e.g person, organisation, server other entity) to a transaction The trusted third-party, known as a certification authority (CA), issues parties with a digital certificate, signed by the CA, including a public key for the party, thus binding the public key to the identity of the party Assuming one party to a transaction trusts the CA, they can rely on the PKI Certificate of the other party to authenticate them In practice a party having a PKI certificate can sign a message with a private key and a recipient of the message can confirm its authenticity, and hence the authenticity of the sender of the message, by using the senders public PKI certificate. The recipient can also subsequently use the sender's public key (obtained from the certificate) to encrypt any replies to the sender (the sender using their matching private key to decrypt the message).

It is impractical for one CA to service the entire demand that exists for issuing certificates.

There are in fact a number of commercial CAs, including for example VeriSign It is also common to have a tiered arrangement in which a chain of certificates are relied upon to confirm a party's identity, the authenticity of one certificate issuing authority being confirmed by a certificate issued by a higher-level CA A PKl or other similar certificate based approach can be a very effective way of ensuring the authenticity of large organisations, but the complexity of the system means it is generally impractical for authenticating the identity of individuals (e.g a bank's customers) Where individuals are authenticated with a public certificate, typically they must carry a smart card with them on which the certificate is stored, which is often not convenient and might be easily lost or stolen.

For these reasons, individual users tend to be authenticated using more straightforward, and as a consequence less secure, schemes. Many systems simply rely on the user providing one or more passwords, or specific characters from a password. With these approaches the user is burdened with remembering multiple passwords and they are inherently less secure because the passwords can be obtained through fraudulent means such as the Phishing attacks referred to above, key-logging spyware or simple observation by a third party More sophisticated systems use one time passwords These are significantly more secure that static passwords, but as with certificate based approaches they require a user to possess a dedicated device (password calculator) to generate the passwords An authentication scheme that provides the strength of a certificate based scheme but that is practical to deploy widely to individual would be extremely desirable but to date no one has met this challenge

Summary of Invention

The present invention proposes an authentication process between two parties communicating with one another from respective devices over a network, involving the exchange of authentication tokens, wherein at least one of the tokens is a device fingerprint of one of the parties' devices. The other token may be a digital certificate, for instance a public key (e g. PKI) certificate. The device fingerprint in effect serves the role of a digital certificate, providing strong authentication without the need for a user to carry a smart card or similar -instead, the fingerprint of the user's device can serve to authenticate them.

The term "transaction" used herein does not necessarily mean a commercial transaction involving a payment, although it includes this. The term includes the sending and or receiving of any network message (e g. request and/or response) or other data to or from either or both of the parties. Generally the transaction, subsequent to authentication of the parties, will involve an exchange of network messages or other data but in some embodiments the communication may be one way only once the authentication process is complete.

A "device fingerprint", as that term is used herein, is an identifier, preferably a unique identifier, for a device. The fingerprint is preferably based on one or more physical properties of the device, most preferably a combination of more than one The physical properties may be any one or more properties of one or more component parts of the device, for example properties of a processor (e.g CPU), such as the serial no. or ID of the processor; a storage unit (e g a hard disk), such as serial no, volume no., or a geometric property such as capacity or sector format; a video card, such as serial no.; volatile or non-volatile memory components (e g. RAM chips or flash memory chips), such as serial no. or capacity, hardware interfaces (e g network adapters), such as serial no. or transfer rate; etc Preferably the fingerprint is derived from at least three or more physical properties of the device, more preferably 4 or 5 or more. It may be based on as many as 10 or more properties It is also preferred that the fingerprint is derived from the properties of two or more separate components of the device, preferably three or more separate components of the device The fingerprint may be calculated as a function of values associated with the chosen physical properties of the device (e g. if one of the chosen properties is hard disk capacity and the capacity is 81,956,655,104 bytes, then the value used in the function could be 81956655104).

The finger print may for example be calculated as a hash function of values of the chosen physical parameters. In some preferred embodiments of the invention is a hash function based MAC (Message Authentication Code) of the combination of the chosen physical properties In a first aspect, the present invention provides a method of authenticating the parties to a transaction over a network, the network communication being between a first device associated with a first party to the transaction and a second device associated with a second party to the transaction, the method comprising: the first party to the transaction sending from the first device a first authentication token to the second party to the transaction; the second party sending from the second device a second authentication token to the first party; the first party verifying the second token received from the first party; and the second party verifying the first token received from the first party; the transaction proceeding if both tokens are successfully verified, wherein at least one of the authentication tokens comprises or is based on a device fingerprint of the device from which it is sent.

The other token may be a digital certificate, for instance a public key (PKI) certificate.

Alternatively it may also be a device fingerprint.

The second party may verify the first token before sending the second token to the first party The verification of each token may be by comparing the token with a copy stored on or accessible to the receiving device. This verification preferably happens automatically without any user input A copy of the fingerprint of one device may be sent to and stored at the other device during an initial registration procedure.

In the case where the token is a PKI-Certificate, the Certificate may be displayed on screen for manual (visual) verification by the user in a normal way.

In some embodiments, one or both of the parties will have more than one device associated with them In this case, the verification step may be completed by comparing the received finger print token with copies of the fingerprints for the multiple devices, the verification succeeding if any one matches. Alternatively, a party having multiple associated devices can indicate which of the devices is being used for the current transaction.

Once both tokens have been verified, the transaction can proceed. Preferably, one of the parties to the transaction provides a session key to the other party once verification is used, the session key being used to encrypt and decrypt subsequent messages between the parties during the transaction session. The session key can also be used to digitally sign the transaction for non-repudiation purposes.

Typically one of the parties to the transaction will be a user (customer) participating in the transaction via a client device connected or connectable to the network. The client device may, for example, be a desktop, laptop or handheld personal computer or a mobile telecommunications device such as a cellular or satellite telephone The connection from the client device to the network may be a wired or a wireless connection The network will typically be a public network such as the Internet for example.

The other party to the transaction will typically be an organisation participating in the transaction (generally in an automated fashion) via a server connected to or connectable to the network.

In a second aspect, the invention provides a system, operable in accordance with the method of the first aspect above, for authenticating first and second parties to a transaction over a network, the system comprising: a first device associated with a first party to the transaction, connected or connectable to the network; and a second device associated with a second party to the transaction, connected or connectable to the network the first and second devices each comprising: means for providing an authentication token for transmission to the other device; means for transmitting authentication tokens to the other device across the network, means for receiving authentication tokens from the other device sent across the network, and means for verifying a received authentication token; wherein at least one of said means for providing an authentication token is adapted to provide an authentication token comprising or based on a device fingerprint of the device providing it.

The means for providing an authentication token may comprise a memory storing the authentication and means for retrieving a copy of the authentication token from the store for transmission to the other device.

However, particularly in the case where the authentication token comprises the device fingerprint, it is preferred that the token is constructed when it is needed, rather than a copy being stored on the device whose fingerprint it is. The device fingerprint can be acquired when needed and used to construct the token. By constructing the token on the fly' in this way, it avoids the possibility that someone obtains a copy of a token based on the fingerprint of the original device and uses it to fraudulently masquerade as the authentic user from another device In other words, it ties the token to the specific device.

To enable this, the means for providing an authentication token may comprise means for constructing the authentication token, preferably including means for deriving the device fingerprint The various "means" of the system are preferably provided by software code, embodied for example in firmware or software resident on the respective devices.

Each device may be a personal computer (e.g. desktop, laptop, handheld), PDA (personal digital assistant), mobile (e.g cellular or satellite) telephone or other portable communication device, or some other dedicated or general-purpose computer (e.g. a server).

Preferably the first device is a client device associated with a user (customer) and the second device is a server. The authentication token for the client device is preferably its device fingerprint In a third aspect, the invention provides a device for use in a system according to the second aspect above, the device comprising means for providing an authentication token for transmission to another device; and means for transmitting the authentication token to another device across a network; wherein the means for providing an authentication token is adapted to provide an authentication token comprising or based on a device fingerprint of the device In a fourth aspect the invention provides a device for use in a system according to the second aspect above, the device comprising means for receiving authentication tokens from another device sent across a network, and means for verifying a received authentication token; wherein the means for verifying the authentication token is adapted to verify an authentication token comprising or based on a device fingerprint from said other device In another aspect, the invention provides a computer program comprising code that is executable on a computer or computer network to cause the computer or computer network to operate in accordance with the method of the first aspect above. The invention also provides a computer readable medium comprising this computer program.

Brief Description of Drawings

Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which: Fig 1 shows schematically a system operable in accordance with an embodiment of the present invention; Fig. 2 schematically illustrates interactions between a client and server of the system of fig. I in accordance with the embodiment of the invention, Fig. 3 illustrates in more detail some aspects of the process of fig. 2.

Description of Embodiment

Figure 1 illustrates a system for completing a transaction between a user 2 and an online service resident on a server 4 The service may, for example, be a banking service, an e-commerce service or an information service In such transactions it can be important to verify the authenticity of both the user 2 and the server 4.

Preferred embodiments of the present invention propose to achieve this authentication by an exchange of authentication tokens The server's token is a PKI certificate. The user's token is (or at least includes or is based on) a device fingerprint of a client device 6 associated with them, that they have pre-registered with the service on the server 4 and from which they will complete the transaction The client device 6 and the server 4 communicate with one another over the lnternetlO.

Fig. 2 illustrates the authentication method used in the system of fig. I and in particular illustrates the exchanges of network messages between the user's (customer) client device 6 and the server 4 The authentication process is controlled by an authentication application or software module running on the client device 6, for instance a browser application or a plugin for a browser application, and a corresponding application or module on the server 4.

Prior to completing any transactions, the user 2 must first register with the server 4. In the -preferred embodiment illustrated in fig. 2 this registration procedure is a multi step-process.

First the user submits a registration request to the server 4, from their client device 6, including their at least their email address and a password. They may additionally be asked to provide a unique user name or their email address may serve as their user name The user is then sent an email to the address they have provided, the email including an activation code. The user must enter the received activation code into an activation web page of the service running on the server 4 before the registration process can be completed. This guards against a new user providing a false email address (either intentionally or by mistake).

The final step in the registration process is for the authentication application or module running on the client device constructs an authentication key for the device 6, based on the devices fingerprint, and sends this to the server 4 where it is stored and associated with the user's user name (email address) and password Once registered with the server 4, the user 2 initiates a transaction with the server 4 using their client device 6. For instance, they may open a web browser application and navigate to a particular web page associated with the particular service on the server 4 in which they are interested.

As part of the process of initiating the transaction with the server 4 the user is required to submit to the server their user name (e g. their email address) along with the password they submitted at the time of registration.

The server receives the user name and password and, assuming they are valid, sends its PKI certificate to the user's client device 6 The certificate is displayed to the user, who verifies it to establish the authenticity of the server 4. If the verification succeeds, the fingerprint of the client device 6 is obtained and based on this the user's authentication token is created and sent to the server 4 The user's authentication token may be the fingerprint itself or derived from it. In any event, as illustrated in fig. 3, the token (e.g fingerprint) is encrypted with the server's public key (obtained from the server's PKI Certificate) before it is sent to the server.

As seen in fig. 3, the server receives the encrypted authentication token (e g. fingerprint) from the client and decrypts it using the server's private key The server 4 then verifies the user's authentication token (device fingerprint) by comparing it with the version stored by the server during the registration procedure, to confirm the authenticity of the user. In this way, there is strong two-factor authentication of the user (password and device fingerprint). Assuming the verification succeeds, the transaction can proceed.

The exchange of tokens (device fingerprint and PKI-Certificate) can be achieved in any of a number of possible way, including for example by using modified headers in network messages that the parties exchange (e.g HTTP headers in HTTP messages) It is generally desirable that subsequent messages between the client device 6 and the server 4 are transmitted securely To enable this, once the identity of both parties has been verified in the manner described above, a random session key is exchanged and subsequently used as a cryptographic key to encrypt and decrypt the messages (e g web forms) passing between the server 4 and the client device 6. Standard PKI encryption algorithms can be used.

More specifically, as illustrated in fig 3, the server creates a nonce ("number-used-once") or some other random sequence of data (e g. a salt) and sends this to the client 6. On receipt of the nonce, the client 6 creates a random session key, which it then encrypts (with the server's public key), along with the nonce, and sends this encrypted data to the server 4. The server 4 receives the encrypted session key and decrypts it. Both parties are then in possession of the random session key, which can then be used to encrypt subsequent messages and also to sign the transaction for non-repudiation purposes This approach provides an inbuilt resistance to man-in-the-middle attacks because the session key is secret. What is more, the use of the nonce also means that a replay attack cannot succeed.

If desired, some or all of the messages passing between the parties, even if not encrypted, may be digitally signed with the parties' respective authentication tokens (e g. device fingerprint and PKI-Certificate). This may be desirable for non-repudiation purposes for example For instance, a public/private key pair can be derived for the client from the device fingerprint, with the client's private key derived in this way being subsequently used for digital signature purposes The skilled person will appreciate that the specific embodiment described above is given by way of example only. Many and various modifications are possible within the scope of the invention. :10

Claims

Claims 1. A method of authenticating the parties to a transaction over

a network, the network communication being between a first device associated with a first party to the transaction and a second device associated with a second party to the transaction, the method comprising: the first party to the transaction sending from the first device a first authentication token to the second party to the transaction; the second party sending from the second device a second authentication token to the first party; the first party verifying the second token received from the first party; and the second party verifying the first token received from the first party; the transaction proceeding if both tokens are successfully verified; wherein at least one of the authentication tokens comprises or is based on a device fingerprint of the device from which it is sent.

2. A method according to claim 1, wherein the other token is a digital certificate.

3. A method according to claim 1, wherein the other token is a device fingerprint.

4. A method according to any one of the preceding claims, wherein the second party verifies the first token before sending the second token to the first party.

5. A method according to any one of the preceding claims, wherein the verification of each token is by comparing the token with a copy stored on or accessible to the receiving device.

6. A method according to any one of the preceding claims, wherein one or both of the parties have more than one device associated with them, the verification step being completed by comparing the received finger print token with copies of the fingerprints for the multiple devices, the verification succeeding if any one matches.

7. A method according to any one of the preceding claims, wherein once both tokens have been verified one of the parties to the transaction provides a session key to the other party, the session key being used to encrypt and decrypt subsequent messages between the parties during the transaction session.

8. A method according to claim 7, wherein the session key is also used to digitally sign the transaction.

9. A method according to any one of the preceding claims, wherein one of the parties to the transaction is a user participating in the transaction via a client device connected or connectable to the network.

10. A method according to claim 9, wherein the other party to the transaction is an organisation participating in the transaction via a server connected to or connectable to the network.

11. A system for authenticating first and second parties to a transaction over a network, the system comprising: a first device associated with a first party to the transaction, connected or connectable to the network; and a second device associated with a second party to the transaction, connected or connectable to the network the first and second devices each comprising: means for providing an authentication token for transmission to the other device; means for transmitting authentication tokens to the other device across the network; means for receiving authentication tokens from the other device sent across the network; and means for verifying a received authentication token; wherein at least one of said means for providing an authentication token is adapted to provide an authentication token comprising or based on a device fingerprint of the device providing it.

12. A system according to claim 11, wherein the means for providing an authentication token comprise a memory storing the authentication and means for retrieving a copy of the authentication token from the store for transmission to the other device.

13. A system according to claim 11, wherein the authentication token comprises a device fingerprint and the means for providing an authentication token comprises means for constructing the authentication token, including means for deriving the device fingerprint.

14. A device for use in a system according to claim 11, the device comprising: means for providing an authentication token for transmission to another device; and means for transmitting the authentication token to another device across a network; wherein the means for providing an authentication token is adapted to provide an authentication token comprising or based on a device fingerprint of the device.

15. A device for use in a system according to claim 11, the device comprising: means for receiving authentication tokens from another device sent across a network; and means for verifying a received authentication token; wherein the means for verifying the authentication token is adapted to verify an authentication token comprising or based on a device fingerprint from said other device.

16. A computer program comprising code that is executable on a computer or computer network to cause the computer or computer network to operate in accordance with a method according to any one of claims 1 to 10.