HK1115955B - Authentication device and/or method - Google Patents

Description

Authentication apparatus and/or method

This application claims priority to australian provisional patent application No.2004907210 filed on 21/12/2004, the contents of which are incorporated herein by reference.

Technical Field

The invention relates to a method and a device for authenticating a remote service to a user. In a typical application, the authentication method or apparatus may be used to authenticate a remote service, such as a site, to a user operating a workstation connected to a communications network. However, the authentication device or method may also be used to authenticate the user to the remote service, or indeed, to mutually authenticate the remote service and the user.

Background

Generally, conventional authentication methods and apparatus allow a user to be authenticated to a remote service. In general, conventional authentication methods require an authentication service to authenticate a user simply by requesting a password from the user.

Often, the user has no way of knowing whether he or she is actually communicating with the desired or correct remote service. Thus, if the remote computer is able to mimic the behavior of the remote service, the user may be spoofed or "induced" (phish) by mistake assuming that he or she is communicating with the correct remote service. As a result, unsuspecting users may leak information that they would otherwise only have to disclose to legitimate remote services, such as their user ID and password, for example.

It is therefore an object of the present invention to provide an authentication apparatus and/or method adapted to authenticate at least a remote service to a user.

The discussion of the background to the invention herein is included to explain the context of the invention. It is not an admission that the material referred to was published, known or part of the prior art at the priority date of the application.

Disclosure of Invention

The invention provides a method of authenticating a remote service to a user by means of a communication network, the method comprising:

the remote service obtains a service authentication code generated by a code generation algorithm based on a first key;

transmitting the service authentication code to the user via the communication network;

receiving or inputting the service authentication code into an authentication device associated with the user;

the authentication device generating an expected code value using the same code generation algorithm based on a second key and then comparing the expected code value with the service authentication code; and is

In response to the comparison and in the event that the expected code value correlates with the service authentication code, the authentication device generates a response indicating to the user the authenticity of the remote service.

In order for the authentication device to generate a response indicating to the user that the remote service is authentic, the first key must be the same as the second key. If the first key is different from the second key, the expected code value will be different from the service authentication code, and therefore the authentication device will not authenticate the remote service.

In an embodiment, the remote service obtains a service authentication code from an authentication server that generates the service authentication code based on a first key obtained from a database in response to a request from a user.

In an embodiment, the second key is a key uniquely associated with the authentication device.

The type of remote service to be authenticated may vary. Generally, the remote service will include an e-commerce service. As will be appreciated, an e-commerce service is a remote service that utilizes programmed computer and communication technologies to purchase and sell goods and services. In an embodiment, the remote service may include: "network-based" e-commerce services (e.g., network-based banking services), user account management services (e.g., telephone account management services), shared trading services, reservation services, order processing services, inventory management services, online transaction services, online shopping services, electronic messaging services for conducting financial transactions.

With respect to suitable communication technologies, suitable communication networks may include packet-based communications supported by a network (e.g., a TCP/IP local area network, or the Internet), a Wireless Application Protocol (WAP) network, a telephone network (e.g., the public switched telephone network), or other suitable communication network. As will be appreciated, the above examples of remote services and communication networks are merely exemplary and should not be construed as limiting. Additionally, and as will be appreciated, the actual communication network will depend on the type of remote service and the required interconnection between the service and the user in order for the user to access the service. For example, where the remote service is a network-based service accessible by a client workstation user, the communications network may be the Internet.

In an embodiment, the code generation algorithm for generating the service authentication code is provided by the remote service. However, in an alternative embodiment, the code generation algorithm is provided by an authentication server that is remote from the remote service but accessible thereto to generate the service authentication code in response to a request from the remote service. In this embodiment, the authentication server provides the service authentication code to the remote service after the service authentication code has been generated.

In an embodiment, the generation of the service authentication code requires encoding a first key to provide the service authentication code. The first key may be encoded using any suitable code generation algorithm to provide the authentication code. One suitable code generation algorithm encodes the single key using a first pseudo-random code sequence and a second pseudo-random code sequence, the second pseudo-random code sequence having a sequence length that is the same as the sequence length of the first pseudo-random code sequence. According to this embodiment, the code generation algorithm employs different first and second pseudo-random encoding sequences each time a service authentication code is generated.

In an embodiment, the first pseudo-random encoding sequence comprises a sequence of single-occurrence characters (e.g., such as alphabetic, numeric, and/or alphanumeric characters) forming a character set, and the character set comprises characters of the first key. That is, in one embodiment, the first key is derived from the same character set that was used to form the first pseudorandom encoding sequence. In this respect, throughout the present specification, reference to the term "character set" should be understood to refer to a character set comprising numeric characters, or alphanumeric characters, or alphabetic characters. In addition, the reference to the term "single occurrence" should be understood to refer to a set of characters in which each character occurs only once.

In an embodiment, the second pseudo-random encoding sequence comprises an arrangement of characters from the same or different character set as the first key. However, in an embodiment, the sequence length of the second pseudo-random code sequence is the same as the sequence length of the first pseudo-random code sequence. In this regard, throughout the text, the term "sequence length" should be understood as the number of characters in the referenced sequence. Thus, a sequence of a coding sequence comprising ten characters is ten in length.

Because the service authentication code and the expected code value are generated using the same code generation algorithm, each instance of the code generation algorithm employs the same first and second pseudo-random encoding sequences to generate the service authentication code or the expected code value, respectively.

In a code generation algorithm applying first and second pseudo-random encoding sequences of the type described above, encoding the first key to produce the service authentication code may comprise:

sequentially identifying the positions of characters in a first pseudorandom encoding sequence corresponding to the characters of the first key or the second key;

mapping the positions of the identified characters in the first pseudo-random code sequence to characters of a second pseudo-random code sequence having the same sequence positions to provide a set of characters from the second pseudo-random code sequence; and

arranging the character set of the second pseudo-random code sequence in the order of identification, thereby forming the service authentication code.

In an embodiment, whenever a service authentication code is generated, different first and second pseudo-random encoding sequences are used to reduce the likelihood of repeatedly generating the same service authentication code. Thus, in one embodiment, each service authentication code is effectively a single-use available code.

The first and second pseudo-random code sequences for a particular code generation event may be selected by an instance of a code generation algorithm that provides a service authentication code to a remote service. In this regard, throughout this specification, the term "code generation event" as referred to should be understood as a single iteration of the code generation algorithm.

In an embodiment, the first and second pseudo-random code sequences are selected from respective arrays of code sequences such that a different first and second pseudo-random code sequence is selected each time a service authentication code is generated.

In embodiments that include first and second pseudo-random encoding sequences as respective arrays of array elements, each array supports a limited number of code generation events. The number of code generation events generally corresponds to the number of array elements in the array. In one embodiment, after each sequence in the array is used to generate the service authentication code, each character in each array element is controllably shifted to a different position in the array element to change the corresponding encoding sequence.

As described above, each instance of the code generation algorithm applies the same first and second pseudo-random encoding sequences to produce a service authentication code or expected code value, respectively. Thus, in an embodiment wherein the first and second pseudo-random encoding sequences for a particular code generation event are selected by a code generation algorithm that produces a service authentication code, the method further comprises:

transmitting an identifier to the user, the identifier identifying the first and second pseudo-random encoding sequences used to generate the service authentication code; and is

The identifier is received or entered into an authenticating device associated with the user for use by a code generation algorithm of the authenticating device to identify first and second pseudo-random encoding sequences to be used to produce a desired code value based on the second key.

Generally, the service authentication code will be communicated to the user using a communication protocol supported by the communication network. For example, for an internet-based remote service, the communication may include an HTML file that includes a uniform resource identifier (URL) that links the user to a web page that provides a service authentication code. Alternatively, the service authentication code may be communicated through other messaging mechanisms, such as eMail information, a Short Message Service (SMS) text message, an audible message describing the service authentication code (e.g., a message based on MP3 and WAV files), an audio-based message, a graphical message (e.g., a jpeg file), or a multimedia messaging protocol that includes the service authentication code.

In an embodiment, the response generated by the authentication device to indicate to the user the authenticity of the remote service comprises the authentication device providing a valid authentication signal to the user. Further, if the first key and the second key are the same, only a valid authentication signal will be generated.

In another embodiment, the response generated by the authentication device to indicate to the user the authenticity of the remote service includes activating the authentication device to generate the user authentication code based on the third key.

In an embodiment, the third key is a key associated with the user, such as a user Personal Identification Number (PIN). In an embodiment, the user authentication code is used to authenticate the user to the remote service.

In embodiments where a user authentication code is generated to authenticate a user to a remote service based on a third key, the authentication of the user will be performed using the same code generation algorithm as previously described, but will be based on a fourth key that can access the user authentication service. In an embodiment, the user authentication service is provided by a remote service. However, in another embodiment, the user authentication service is provided by an authentication server and the results of the user authentication are communicated to a remote service.

Accordingly, the present invention also provides a method of authenticating a user to a remote service via a communications network, the method comprising:

the authentication device generates a user authentication code by using a code generation algorithm based on the third key;

transmitting the service authentication code to the remote service via the communication network;

the remote service or another service obtains the expected code value that has been generated based on the fourth key, and then compares the expected code value with the user authentication code; and is

In response to the comparison and in the event that the expected code correlates with the service authentication code, the remote service allows the user further access to the remote service.

The present invention also provides a method of mutually authenticating a remote service user and a remote service by means of a communication network, the method comprising:

the remote service acquires a service authentication code generated by a code generation algorithm based on a first key;

transmitting the service authentication code to the user via the communication network;

receiving or inputting the service authentication code into an authentication device associated with the user;

the authentication device generating an expected code value using the same code generation algorithm based on a second key and then comparing the expected code value with the service authentication code;

in response to the comparison and in the event that the expected code correlates with the service authentication code, the authentication device generating a user authentication code value using a code generation algorithm based on a third key;

transmitting the user authentication code to the remote service via the communication network;

the remote service or other service obtaining a second expected code value generated based on a fourth key and then comparing the second expected code value with the user authentication code; and is

In response to the comparison and in the event that the second expected code value correlates with the user authentication code, the remote service allows the user further access to the remote service.

The present invention also provides a software architecture embodied on one or more computer-readable media and for execution on a server, the software architecture comprising:

a service authentication code generator for generating a service authentication code using a code generation algorithm based on a first key, the generation of the service authentication code comprising: encoding the first key by using a first pseudo-random code sequence and a second pseudo-random code sequence with the same sequence length as the first pseudo-random code sequence, wherein the encoding process comprises the following steps:

sequentially identifying the positions of characters in a first pseudorandom encoding sequence corresponding to the characters of the first key;

mapping the sequence positions of the identified characters to characters of a second pseudo-random code sequence having the same sequence positions to provide a character set from the second pseudo-random code sequence; and

arranging the character set of the second pseudo-random coding sequence according to the identification sequence to form the service authentication code; and

a transmit driver for transmitting the service authentication code to a remote user via the communication network;

wherein the service authentication code is altered according to first and second pseudo-random encoding sequences used by the code generation algorithm and different first and second pseudo-random encoding sequences are used whenever a service authentication code is generated to reduce the likelihood of repeated generation of the same service authentication code.

The present invention also provides a software architecture embodied on one or more computer-readable media for execution on an authentication device, the authentication device software architecture comprising:

an input driver for receiving or inputting a service authentication code provided by a remote service, the service authentication code being generated using a code generation algorithm based on a first key;

a generator to generate a desired code value with the code generation algorithm based on a second key;

a comparator for comparing the expected code value with the service authentication code; and

a response generator for generating a response indicating the authenticity of the remote service in dependence on the comparison of the expected code value and the service authentication code.

The present invention also provides an authentication apparatus for providing a response indicating to a user of the authentication apparatus the authenticity of a remote service based on a service authentication code provided by the remote service, the authentication apparatus comprising:

an input device for receiving or inputting the service authentication code, the service authentication code being generated using a code generation algorithm based on a first key;

generator means for generating a desired code value using the same code generation algorithm based on the second key;

comparator means for comparing the expected code value with the service authentication code; and

response generator means for generating a response indicative of the authenticity of the remote service in dependence on the comparison of the expected code and the service authentication code.

In an embodiment, the response generated by the authentication device to indicate to the user the authenticity of the remote service comprises: the authentication device activates to generate a user authentication code for authenticating the user to the remote service. In this embodiment, the user authentication code may be communicated to the remote service to allow the remote service to authenticate the user using the same code generation algorithm as described above but based on the fourth key.

Thus, in this embodiment, the present invention provides an authentication device that is operable only when activated by a valid service authentication code provided by a remote service or other entity, the authentication device then serving to authenticate the owner or user of the authentication device to the remote service or other entity. This will ensure that the authenticity of the site that the user is authenticating to before the user authenticates to the site or entity.

As a result, this significantly reduces the ability to "fraudulently" key in information, unlike other devices currently entering the market, such as scratchcards and some electronic one-time passwords (OTP), because the likelihood of a rogue site or entity that is intended to fool a user into revealing sensitive information will be reduced by guessing, for example, six authentication codes to prove that they are legitimate remote services or other entities that the user will be considered to face. As will be appreciated, the longer the authentication code, the less likely a correct guess.

Preferably, embodiments of the invention that employ a pseudo-random encoding sequence to encode the different keys do not employ digital algorithms used in the device, such as tokens, scratchcards and OTPs. Such devices are based on complex prime-related algorithms, which at the same time may be mathematically crisis.

In an embodiment, the authentication device may comprise or be installed in a portable device that may be held by the user. Another embodiment also includes an authentication server that interprets data sent between the remote service and the user to verify the authenticity of the remote service and the user.

It is envisaged that the present invention will be developed for use in a variety of different applications. For example, the present invention can be used to control access to buildings/confined areas, online election voting (e.g., for election committees or joint management committees), logging into the corporate network from an internal or remote office location/home, and authenticating mail messages as originating from legitimate sources (as opposed to from fraudulent sources).

Preferably, the embodiments of the invention that support mutual authentication may be used by a user to authenticate the identity or other information related to other people (or entities) after having first verified that the user is communicating with a remote service that is capable of legitimately authenticating other people or entities.

Thus, in one embodiment, the present invention also provides methods and systems for verifying the identity and/or credit of other persons or entities. For example, the present invention may be used to verify that a retailer (e.g., an electrical engineer) is licensed by participating in authentication between the retailer, a user, and a remote service that can obtain license status information from regulatory agencies (e.g., consumers and business agencies). By way of further example, and also in relation to embodiments supporting mutual authentication, the present invention may be used to verify diploma from "XX university" held by a job seeker. By way of yet another example, the present invention may be used as part of a ticketing system for authenticating the identity of a traveler for ticketing purposes.

Accordingly, the present invention also provides a method of authenticating the identity and/or credentials of a second user to a first user via a communication network using a remote service, the method comprising:

the first user authenticating the remote service using the aforementioned authentication method;

in the event that the remote service is validly authenticated, the first user providing a user authentication code generated by an authentication device of a second user based on a key associated with or provided by the second user;

transmitting the user authentication code to the remote service via the communication network;

the remote service obtaining an expected code value that has been generated based on a key, and then comparing the expected code value with a user authentication code for the second user; and is

In response to the comparison and in the event that the expected code value correlates with the user authentication code, the authentication apparatus provides a response to the first user indicating the authenticity of the second user.

As will be appreciated, the examples set forth above are non-limiting examples of possible applications of the present invention. It is to be understood that the present invention may, in various embodiments, be deployed in applications beyond those specifically set forth. Indeed, it is envisaged that the present invention is suitable for a wide range of applications, including authentication between a user and a remote service, whether the authentication is unidirectional (in either direction) or mutual (bidirectional).

Drawings

The present invention will now be described with reference to embodiments illustrated in the accompanying drawings. It must be recognized, however, that the following description is not intended to limit the generality of the preceding description.

In the drawings:

FIG. 1 is a system block diagram of a system suitable for performing a method according to an embodiment of the invention;

FIG. 2 is a block diagram of an authentication device according to an embodiment of the present invention;

FIG. 2A is a block diagram of an embodiment of a system including an authentication server in accordance with the present invention;

FIG. 3 is a flow chart describing steps in a method for authenticating a remote service to a user in accordance with an embodiment of the present invention;

FIG. 4 is a flow chart describing steps in a method for authenticating a user to a remote service in accordance with an embodiment of the present invention;

FIG. 5 is a table illustrating an example of a shifting process for shifting a pseudorandom code sequence in accordance with an embodiment of the present invention;

fig. 6 is a table illustrating an example of a further shifting procedure for further shifting a pseudo-random coded sequence according to an embodiment of the present invention.

Detailed Description

FIG. 1 illustrates a system 100 for authentication between a remote service and a user 102 in accordance with an embodiment of the present invention. The system 100 includes a remote service 104 and an authentication device 106, the authentication device 106 being operable by a user 102 to receive a service authentication code provided by the remote service 104 via a communication network 108.

The communication network 108 shown here is a global computer network (e.g., the internet) that includes a network device 110 (here shown as a remote server 112) hosting the remote service 104, a user-operable device 114, and an authentication server 116, each of which is compatible with and connected to the other elements of the communication network 108 to allow communication between the remote server 112, the user-operable device 114, and the authentication server 116. Although the communication network 108 is described in terms of a global computer network, it should be appreciated that the communication network 108 need not be so limited. Indeed, the system 100 used in accordance with another embodiment of the present invention may employ other types of communication networks 108, such as a Public Land Mobile Network (PLMN), a Public Switched Telephone Network (PSTN), or a combination of different types of internet communication networks. As will be appreciated, the network device 110 and the user device 114 will vary depending on the type of communication network 108 employed.

Authentication server 116 may comprise a single processing unit (e.g., a single server), or a set of smaller centralized devices equipped with a suitable operating system. Suitable operating systems may include Windows, Linux, or Solaris. In this respect, when the term "server" is used, we mean: a physical server (i.e., a single machine), or a virtual server (i.e., more than one function on the same physical machine), or a service or set of servers/services (i.e., multiple physical or virtual devices capable of load balancing, backup, scalability).

In the illustrated embodiment, the authentication device 106 may be used to authenticate the remote service 104 to the user 102 and/or to authenticate the user 102 to the remote service 104 via the communication network 108.

Fig. 2 shows a block diagram of an embodiment of the authentication device 106. As shown, the authentication device 106 may be any consumer or commercial device with a processor 200, its own memory 202, an input device 204 (e.g., a keypad 208 for entering input values), and a power source 206, the authentication device 106 including, but not limited to, a mobile phone, a personal data assistant (e.g., HP IPAQ, Palm tilt, etc.), and a portable music player, or a custom device (e.g., a smart card), the authentication device 106 with a software program 210 installed by the manufacturer or by the user. The software program 210 is stored on the carried memory 202 in the form of a set of processor-executable instructions.

The processor 200 executes an input driver provided in the instruction set to allow the input device 204 to be manipulated by a user to receive or input a service authentication code into the authentication device 106. In this case, processor 200 is a Texas Instrument MSP-430. However, it should be appreciated that any suitable processor may be used.

Upon receipt or input, the processor 200 uses the same code generation algorithm as used to generate the service authentication code to generate the desired code value based on the key associated with the authentication device. The processor 200 also executes the set of instructions to provide a comparator tool for comparing the expected code value with the service authentication code to generate a response indicative of the authenticity of the remote service based on the comparison of the expected code with the service authentication code. As shown, the input device 204 further includes: a clear button 212 capable of re-entering the input value; an unlock button 214 that unlocks the authentication device 106 for use after the service authentication code provided by the authentication server 116 has been entered. The illustrated input device 204 of the authentication device 106 further includes: an "ACT" button 220 that is pressed while displaying the activation code; a "PIN" button 222 for encoding the user's PIN after it has been entered to generate a user authentication code.

As shown, an output display 224, such as an LCD display, is also provided to provide information, such as instructions, and to provide important inputs to the user.

A response means is also provided, here shown as a pair of indicators including a red LED indicator 216 and a green LED indicator 218, wherein the red LED indicator 216 is illuminated when the service authentication code is not associated with the expected code value and the green LED indicator 218 is illuminated when the service authentication code is associated with the expected code value. Although the illustrated authentication device 106 includes a response device in the form of a pair of LEDs, it will be appreciated that any suitable response device may be used. For example, in another embodiment, the responding device may include a tone generator that produces a tone that can indicate to the authenticating device 106 to authenticate the remote service 104.

In an embodiment, in addition to the executable program instructions 210, the memory 202 carried by the authentication device 106 itself contains pre-programmed data items as determined in the following list. It is to be understood that the following list is exemplary only.

1. An activation code;

2. a key (hereinafter referred to as "DPIN") associated with the authentication device 106;

3. a first pseudo-random code Sequence (hereinafter referred to as a "Device challenge Sequence") for remote service authentication;

4. a second pseudo-random encoding sequence (hereinafter referred to as a "device encoding sequence" (DES)) for remote service authentication;

5. a first pseudo-random encoding sequence (hereinafter referred to as a "user password sequence" (UCS)) for user authentication;

6. a second pseudo-random encoding sequence (hereinafter referred to as a "user encoding sequence" (UCS)) for user authentication;

7. a coding sequence shift sequence (ESDS);

8. code sequence shift sequence reference (ESDSREF);

9. a password sequence shift sequence (CSDS);

10. password sequence reference (CSREF);

11. coding sequence reference (ESREF); and

12. a PIN shift code (PDC);

the function of each of the data items listed above is briefly summarized in the following description.

Activation code:

the activation code is an x-bit alphanumeric code that is unique to each authentication device and serves as a tool to both register the authentication device 106 and activate a response from the remote service or authentication server 116. The use of the activate code will be described in more detail below.

The activation code may include any suitable code scheme. In an embodiment, the activation code comprises a six-bit character code from a character set that includes twenty-four alphabetic characters (of course, "O" and "I" are not used because they may be confused with 0 and 1) and all ten numbers between "0" and "9". This scheme provides 15.45 billion combinations (34X 34).

In the description below, a six-bit activate code will be used as exemplified below: "RF 6D 9S".

Device pin (dpin):

DPIN is a pseudo-random x-bit code that remains fixed relative to its associated authentication device 106. Here, DPIN is a code uniquely associated with the authentication device 106. There is no correlation between the activate code and the DPIN.

During authentication of remote service 104, DPIN is used as part of a service authentication code that is transmitted between authentication server 116 and authentication device 106.

In an embodiment, the DPIN comprises a four character number sequence. The chance that the sequence was guessed is 1/10000. In the example below, a four-bit DPIN of "6794" will be used.

Device password sequence (DCS) code:

each DCS code is a code that is used by the authentication apparatus 106 based on the DPIN of the authentication apparatus 106 in generating a desired code value. Typically, the authentication device 106 will store a plurality of unique DCS codes. In this case, each DCS code includes a sequence of unrepeated digital characters. In the following example, the following four DCS examples will be used: "2196758304", "0123456789", "6387109245", and "8253614709".

Device Encoding Sequence (DES):

DES is a pseudo-random encoding sequence used to authenticate multiple service authentication codes. Although the length of the DES should not be significant in practice, the lower the number, the greater the shift complexity and thus the number of required service authentication codes, given the endian shift.

Typically, the DES will be between five hundred and one thousand sequence bits in length. The length of the range will allow between fifty and one hundred uses before a shift is required. However, in an embodiment, the DES has a length of at least five hundred bits to enable at least fifty authentication cycles. In the example below, the example of a twenty-bit DES will be used (this will enable verification of two service authentication codes):

“73619482640194827351”。

user password sequence (UCS) encoding:

in an embodiment, the UCS code is used to encode a user PIN entered by the user, thereby providing a user authentication code. In this case, the UCS code is used as many times as there are more tens digits in the UES.

However, the increased complexity may be a round-robin use of such UCS codes, further eliminating any possible correlation between OTP and UES from a cryptographic perspective.

The UCS code is used as a tool to encode a PIN entered by the user. In the following example, the following four UCS examples will be used: "6387109245", "8253614709", "2196758304", and "0123456789".

User Encoding Sequence (UES):

the UES is a pseudo-random code sequence used to encode the x user-selected PINs. Preferably, the sequence is at least five hundred digits in length, so that fifty user-selected PINs can be encoded.

Like DES, the length of the UES should not be really important. However, to avoid overcomplicating the shifted sequences, it is preferred that the sequence length is between five hundred and one thousand bits, so that between fifty and one hundred times can be used.

A one thousand bit UES would provide nearly 32 x 10¹⁵³⁰A possible variation. In the following example, the following example of a twenty bit UES will be used: "A23 CTBLM4S5RT7P6SJK 9". Illustrated twenty-bit UES will be able to encode the user selected PIN twice.

Coding sequence shift sequences (ESDS):

in an embodiment, the ESDS shift sequence is used to generate the "new" DES and UES.

However, to avoid sequences as long as DES and UES themselves (in which case new DES and UES may also be defined), the ESDS may actually be repeated multiple times. For example, for a DES and UES of five hundred to one thousand bits, the ESDS should be one hundred bits of encoding, which in practice requires between five and ten shift codes.

Once DES and UES have been used x times (DES and UES divided by ten to get the x value used), x ESDS shifts both DES and UES.

Each of the x shifted sequences is based on an x (e.g., one hundred) bit number sequence used to enable shifting of DES and UES.

For example, a five one hundred bit ESDS sequence can be used to shift the five hundred bit DES and UES, each ESDS can be used to cope with each one hundred bit DES and UES.

1. 06.16.09.13.01.03.19.12.18.14.05.08.07.10.02.17.20.11.15.04

2. 07.20.09.02.11.08.16.01.10.15.03.17.05.14.04.12.19.06.18.13

3. 10.04.14.01.20.05.13.09.03.12.17.08.11.19.02.18.06.16.07.15

ESDS reference (ESDSREF):

the ESDSREF reflects which of the DES and UES shifted sequences is in use and is preset to "1", but is incremented each time the shifted sequence is completed. Thus, if there are five ESDSSs, the ESDSREF will cycle between one and five.

Password sequence shift sequence (CSDS):

the CSDS includes a digital code that is used to construct the x-bits DES and the first bit of the UES, thereby constructing the first ten-bit block of x-bits available in each sequence. For example, three "twenty" bit CSDS numbers include 6, 13, 17. In another example, a five "five hundred" bit CSDS number includes: 083. 136, 276, 343, 435.

CSDS reference (CSDSREF):

the number of CSDSs used is reflected by the CSDSREF, which will therefore cycle between 1 and the total number of CSDSs used. Thus, CSDSREF reflects which of the CSDSS is in use and is preset to "1".

CS reference (CSREF):

CSREF reflects which of UCS and DCS is being used and is preset to "1". The above process may loop after each shift sequence for each entry, or for added complexity. To make the complexity even greater, 1 can be added for each shift sequence, and then when each of the UCS and DCS codes has been used once, they then loop at each user login.

Coding sequence reference (ESREF):

the ESREF is used to ensure that the authentication device 106 remains synchronized with the authentication server 116 in the unlikely event that the user 102 enters a valid service authentication code that does not originate from the authentication server 116.

PIN shift coding (PDC):

in an embodiment, the PDC is used to construct a virtual PIN that changes after every x uses by the authentication device 106. The PDC will be used to change the actual user PIN, which is selected to obtain a unique six-digit PIN at a time, regardless of whether the user PIN selected by the user is a four-digit, five-digit or six-digit PIN.

Each time a DES and UES shift sequence is used, x PDCs will be used and simply used to change the user selected PIN, thereby building a virtual new PIN each x times the authentication device 106 is used. In the case where the above change constitutes a negative value, the same numerical digit will be used to change it to a positive value. The PDC is completely random.

PDC provides additional complexity and may occupy unnecessary memory. Their use will not be described in detail for the purposes of this specification, although it will be appreciated that each time the user uses the authentication device 106, this effect will cause the user's PIN to simply be changed to a virtual PIN and then encoded.

Authentication server composition and data

In fig. 2A an embodiment of a system comprising an authentication server 116 is shown, in which embodiment a generator server 226 generates a dpin that is loaded onto the authentication device 116 and the authentication server 116, the data then being distributed to the end user of the data, in which case if a copy is made and downloaded onto a phone, PDA, internet appliance or the like, then a copy is sent to the user storage device 230 and a copy is sent to the terminal authentication device 106.

The activation code and address of user store 230 are sent to directory server 228, which are then read or updated by redirect server 230.

In the illustrated embodiment, when attempting registration, redirect server 230 reads directory server 228 (or a local copy of the directory) and sends an authentication request to authentication server/group 116 storing a server-side version of the DPIN. For example, the user may log in via remote service 104, which remote service 104 then redirects the request directly to a bank, or to a publishing organization that notifies user 104 of authentication device 106. This step can be "federated".

Authentication server 116 performs the computational functions of the code generation algorithm and stores the current state of variables or the like in user storage associated with the user.

The following sections describe the composition of data stored on the authentication server 116 relating to each authentication device 106. It should be understood that the following list is exemplary only.

1. An activation code;

2. a secret key (DPIN) associated with the authentication device 106 registered with the authentication server 116 and, thus, registered to access the remote service.

3. A first pseudo-random code sequence (hereinafter referred to as a "device password sequence" (DCS)) for remote service authentication;

4. a second pseudo-random code sequence for remote service authentication (hereinafter referred to as "device code sequence");

5. a first pseudo-random encoding sequence (hereinafter referred to as a "user password sequence" (UCS)) for user authentication;

6. a second pseudo-random encoding sequence (hereinafter referred to as a "user encoding sequence" (UCS)) for user authentication;

7. a coding sequence shift sequence (ESDS);

8. code sequence shift sequence reference (ESDSREF);

9. a password sequence shift sequence (CSDS);

10. password sequence reference (CSREF);

11. coding sequence reference (ESREF); and

12. PIN shift code (PDC).

FIG. 3 illustrates a flow chart of a method 300 of authenticating a remote service 104 to a user 102.

As shown, method 300 includes step 302, in which remote server 104 obtains a service authentication code, which has been generated using a code generation algorithm based on a first key.

In step 304, the service authentication code is transmitted to the user 102 via the communication network.

The service authentication code is then received and input to an authentication device associated with the user 102 in step 306.

The authentication device 106 uses the same code generation algorithm to generate the expected code value based on the second key (in this case, DPIN) in step 308, and then compares the expected code value with the service authentication code in step 310.

Finally, in step 312, in response to the comparison and in the event that the expected value correlates to the service authentication code, the authentication device generates a response indicating to the user 102 the authenticity of the remote service 104. As will be appreciated, if the first and second keys are the same, the expected code generated by the authentication device 106 will only be related to the service authentication code provided by the remote service 104. Thus, if the remote service 104 obtains a service authentication code that has been generated using a key that is different from the second key (i.e., DPIN), the service authentication code will not correlate to the expected code.

As shown, the method 400 includes a step 402 in which the authentication device 106 generates a user authentication code value using a code generation algorithm based on a third key (in this case, a personal identification number entered by the user) in step 402.

In step 404, the user authentication code is communicated with the remote service 104 via a communication network. In step 406, the expected code value is generated by the authentication server 116 based on the fourth key.

In step 408, the expected code value is compared to the user authentication code. Finally, in response to the comparison and in the event that the expected code value correlates to the user authentication code, the remote service 104 allows the user 102 further access to the remote service 104 in step 410.

As will be appreciated, if the third and fourth keys are the same, the expected code generated by the authentication server 116 will only be related to the user authentication code provided by the authentication device 106. Thus, if the authentication device 106 provides a user authentication code that has been generated using a key different from the fourth key (i.e., different from the user's registration PIN), the user authentication code will not correlate with the expected code.

Authentication processing flow

In summary, part or all of the following processes may be performed as part of an authentication service using a method or apparatus according to embodiments of the invention:

1. a user registration process for initially registering the authentication device 106 with the authentication server 116;

2. a "regular login" procedure for allowing a user to authenticate the remote service 104 using their authentication device 106;

3. a "shift process" for shifting each of the UES and DES after each has been used;

4. a process for resetting the user PIN;

5. one or more processes for allowing an authentication method or apparatus to be applied in a multi-service environment;

the following examples of the above and other processes are provided for illustrative purposes.

Example 1: initial registration of an authentication device with an authentication server

The authentication device 106 may be provided to the user prior to registering the authentication device 106 with the remote service 104, where the authentication device 106 may be used to enable access to the remote service 104.

In such embodiments, the user 102 may log in to the remote service 104 using existing credentials, such as a user ID and password. If already logged in, the user 102 may choose to register the authentication device 106 with the authentication server 116. The registration of the authentication device 106 with the authentication server 116 typically includes the steps of:

1. an activation and verification phase;

2. selecting a user PIN; and

3. and registering user information.

Each of the above steps will be described in more detail below.

Activation and authentication

To register the authentication device 106 with the authentication server 116, the authentication server 116 will first cause the user 102 to provide an activation code (in this example: "RF 6D 9S") for the user's authentication device 106. As described earlier, the activation code may be displayed on the display of the authentication device 106 by pressing the "ACT" button 220 (see FIG. 2).

After the activation code has been provided, the authentication server 116 may then respond with a service authentication code to verify that the user 102 is indeed using the authentication device 106 that has been shown to be based on the entered activation code.

Such a Service Authentication Code (SAC), including an encoded DPIN (in this example: "6794"), is retrieved by the authentication server 116 based on the authentication code. In this regard, the authentication server 116 maintains an index of activation codes and associated DPINs for each issued authentication device 106. Thus, upon receiving the activation code, the authentication server 116 can obtain the DPIN associated with the received activation code.

The service authentication code also includes an ESREF, which is a number "01" at initial registration. Thus, in this example, the service authentication code is a six-bit code in conjunction with the DPIN being encoded.

By way of example, using the illustrated twenty-bit DES "73619482640194827351" (i.e., a two ten-bit sequence), and a DCS code reflected by CSREF with an ESREF of "01" (in this example, "1" represents example "2196758304"), a service authentication code will be generated by encoding the acquired DPIN with the DCS code for the first ("01") ten-bit DES, as shown below:

the user 102 then enters the provided service authentication code into the authentication device 106.

The authentication device 106 encodes the DPIN stored on the authentication device 106 (i.e., the DPIN associated with the authentication device 106) against the first ten-bit block of DES stored on the authentication device 106 (the last two bits of the service authentication code are given as "01") and the DCS code.

If a six-digit service authentication code has been entered (in this example: "196401"), the authentication device 106 compares the first four digits of the service authentication code to the corresponding digits of an expected code generated by the authentication device 106 using the DPIN associated with the authentication device 106.

In this example, the process is implemented by pressing a "VER" button (not shown) on the authentication device 106. The authentication device 106 will also detect if the last two bits of the service authentication code are equal to eseref + 1.

If the service authentication code is authenticated, the green LED218 (see FIG. 2) is lit and the "EnterPIN" is displayed on the authentication device display. Then, the ESREF is incremented by one for the next service authentication code. On the other hand, if the service authentication code is not authenticated, the red LED216 (see fig. 2) is lit and a "Try Again" or similar message is displayed on the authentication device display 224 (see fig. 2).

If the service authentication code fails multiple times, the remote service 104 is not valid, or the authentication device 106 being used by the user 102 is not the one that correctly corresponds to the activation code.

Selecting PIN

The user 102 should then select and enter a unique user PIN, and then press the "PIN" button 222 (see FIG. 2). The authentication device 106 will then use the first ten bit block of UES and the first UCS code to generate an encoded user PIN.

By way of example, using the illustrated twenty-bit UES "a 23CTBLM4S5RT7P6SJK 9" and UCS code corresponding to CSREF (e.g., "6387109245"), with a "01" DES block provided with a service authentication code, the user PIN (in this example: 4876) would be encoded as follows:

once the user 102 has entered the encoded user PIN, the authentication server 116 may decode the user PIN and store it for future use in authenticating the user.

An additional step may be taken to verify the user PIN by decoding the user PIN for the second ten bit block of the UES. However, this may confuse the user, and in the event that the user PIN is forgotten, the presence of the Q & a functionality (explained in more detail below) will enable the user to securely reset the user PIN. Further, the authentication device 106 may remain logical, whereby the user-selected user PIN may be verified by requiring a second entry of the user PIN before decoding the user PIN to ensure that the first user PIN is the same as the second user PIN entered.

Q&A

If the user PIN selection has been completed, the user 102 may register its details with a conventional type of Q & A based process. The problem obtained from the Q & a based process can be used to determine the security around the reset process.

If the registration process with authentication server 116 has been successfully completed, then the user's user ID, which is specific to the third party with which authentication device 106 is registering, will be transmitted to authentication server 116.

All the user 102 needs to do is provide their unique activation code and verify their user PIN when they then register their authentication device 106 with another third party for use. The third party may then send the user ID to the authentication device 106 for use when the user authenticates for the particular service. Therefore, it is not necessary to repeat the Q & a process that has already been performed.

This process will enable the authentication device 106 to be used for a variety of remote services while providing the same degree of security.

Example 2A: routine login

The user 102 will log into a particular remote service 104 and the authentication device 106 provides an authentication tool for the remote service 104 by entering an activation code, which is obtained by pressing the "ACT" button on the authentication device 106.

The remote service 104 then transmits the activation code to the authentication server 116. The authentication server 116 then responds with a service authentication code to verify that the user 102 is indeed using the authentication device 106 that has been indicated based on the entered activation code.

Upon sending the service authentication code to the user 102, a timer may be started to limit the validity of the user's encoded user PIN to a predetermined period of time, such as sixty seconds. This will prevent the encoded user PIN from being used if the mirror site successfully matches the service authentication code, and it will also limit the chance of human attack to some extent given that an attacker must respond within a defined time frame to gain access.

This service authentication code consists of an encoded DPIN (in this example: "6794") and an ESREF- -every time authentication server 116 is invoked, the ESREF will add 1. the encoded DPIN and ESREF together construct a six-digit service authentication code.

By way of example, with the illustrated twenty-bit DES "73619482640194827351" (i.e., two ten-bit sequence) and appropriate DCS and CSREF codes, e.g., "6387109245," and an ESREF of "02," the DPIN will be encoded by using the DCS code for the second ("02") ten-bit DES to produce a service authentication code, as described below:

the user 102 must then enter the service authentication code into the authentication device 106, and the authentication device 106 then encodes the DPIN stored on the authentication device 106 against the second ten-bit block of DES (the last two bits of the service authentication code being "02") and using the appropriate DCS code stored on the authentication device.

If the service authentication code has been entered, in this example "047502", the authentication device 106 will then use the DPIN associated with the authentication device 106 to detect whether the first four bits (in this example "0475") match those generated by the authentication device 106.

In this case, the above process is implemented by pressing the "VER" button.

Further, if the service authentication code is authenticated, the green LED218 (refer to fig. 2) will light up, and a prompt such as "Enter PIN" is displayed on the display of the authentication apparatus 106. If the service authentication is not authenticated, the red LED216 (see FIG. 2) will light up and a "Try Again" prompt or other suitable message is displayed on the authentication device display 224 (see FIG. 2).

Entering a PIN

Once the remote service 104 has been authenticated, the user 102 may then enter his unique user PIN and then press the "PIN" button 222 (see FIG. 2).

The authentication device 106 then uses the ten bits of the second block of UES and the appropriate UCS code. By way of example, using the illustrated twenty-bit UES "a 23CTBLM4S5RT7P6SJK 9" and an appropriate UCS code, e.g., "6387109245", and an ESREF of "02" as provided in the service authentication code, the user PIN (in this example: "4876") would be encoded as follows:

the user 102 then provides the encoded user PIN to the authentication server 116, either directly or indirectly, and the authentication server 116 then attempts to match the encoded user PIN with the user PIN stored in or accessed to the authentication server 116. In this case, the process is implemented by the authentication server 116, and the authentication server 116 acquires the DPIN used by the activation code earlier transmitted to the authentication server 1016 and encodes the DPIN, using the same UCS and UES used by the authenticated device 106 to encode the DPIN associated with the authentication device 106.

If the encoded user PINs match, authentication server 116 transmits the appropriate user ID to the third party that is requesting authentication and the determined verification. If not, they will be required to retry and will be sent to the Q & A process after three failed attempts.

Example 2B: secondary federated registration

When a second third party, other than the authentication device issuer, can use their authentication device 106 as a tool for the user 102 to authenticate to the remote service 104, then the user 102 can follow a simple registration process.

First, the user 102 will log into the remote service 104, e.g., site, using their existing credentials, such as user ID and password, according to the third party's standards and security requirements. If it is already logged in, the user 102 will choose to register their authentication device 106.

Activation and authentication

Remote service 104 should first prompt user 102 to activate a code (in this example: "RF 6D 9S"). Further, the activation code is obtained on the display of the authentication device 106 by pressing the "ACT" button. Once provided to the authentication server 116, the authentication server 116 can respond with a service authentication code to verify that the user 102 is indeed using the authentication device 106 that has been shown to be based on the entered activation code.

The service authentication code consists of an encoded DPIN (in this example: "6794") and an ESREF, which is at least greater than "01" at the time of secondary registration, which together constitute a six-digit service authentication code. For example, with the example twenty-bit DES "73619482640194827351" and the DCS code reflected by CSREF (in this example, "2" reflects example DCS "2196758304"), where ESREF is "02", the service authentication code will be generated by encoding DPIN using the DCS code for the second ("02") ten-bit DES as follows:

the user 102 then enters the service authentication code into the authentication device 106, and the authentication device 106 then encodes the DPIN stored on the authentication device with the DCS code also stored on the authentication device 106 for the second ten bit block of DES (assuming the last two bits of the service authentication code are "02").

If the six-digit service authentication code has been entered (in this example: "489102"), the authentication device 106 will detect if the first four digits match those encoded on the authentication device 106. In the illustrated embodiment, this can be accomplished by pressing the "VER" button. The authentication device 106 will also detect if the last two bits of the service authentication code are equal to eseref + 1.

If the service authentication code is authenticated, the green LED218 (see FIG. 2) will light up and an "Enter PIN" can be displayed on the authentication device's display and the ESREF will add 1 for the next service authentication code. If the service authentication code is not authenticated, the red LED216 (see FIG. 2) will light up and a "Try Again" or appropriate message may be displayed on the authentication device display 224 (see FIG. 2). If the remote service authentication fails multiple times, it indicates that the remote service is invalid, or that the authentication device 106 being used by the user 102 is not the correct one for the activation code.

Entering a PIN

Assuming that the authentication server 116 will already be able to determine whether the user 102 has been registered (by their activation code), it does not expect that the user 102 must select a user PIN, but rather the actual user PIN entered, which has been selected for use in registering themselves with the authentication server 116.

The user 102 should then enter their unique user PIN, followed by pressing the "PIN" button 222 (see FIG. 2). The authentication device 106 will then use the appropriate ten bit block of UES and the appropriate UCS code. For example, using the illustrated twenty-bit UES "A23 CTBLM4S5RT7P6SJK 9" and UCS code "6387109245", with ESREF "02" provided to the service authentication code, the PIN (in this example: "4876") would be encoded as follows:

once the user 102 has entered the encoded user PIN, the authentication server 116 may match the encoded PIN, which has encoded the same PIN on the authentication server 116.

If the registration process with authentication server 116 has been successfully completed, then the user's user ID, which is specific to the third party with which authentication device 106 is registering, will be transmitted to authentication server 116.

If the encoded user PINs do not match, they will be required to retry and be sent to the Q & A sequence after three failed attempts.

Example 3: process of displacement

In embodiments including respective arrays including DES, DCS, UCS, and UES, respectively, each array may support a limited number of code generation events, which number corresponds to the number of array elements in the array. Accordingly, after each sequence in the array has been used to generate a service authentication code, each character in the array elements of the array is controllably shifted to a different position in the array elements, thereby changing the corresponding sequence.

Thus, in the illustrated embodiment, the authentication method works based on the number of shifted sequences that effectively shuffles DES and UES after a single use.

Using the exemplary twenty-bit DES and UES (relative to a full x-bit sequence), and the exemplary ESDS and CSDS, the authentication method will work as follows:

1. when each of the two ten bit blocks of DES and UES have been used, if the check indicates that eseref is equal to DES and UES divided by ten and added by one, one after each successful service authentication code, they will be identified and the following steps will be performed:

2. both DES and UES are shifted. This procedure is implemented by using the ESDS corresponding to the ESDSREF, as shown in fig. 5. For example, if ESDREF is "1", the first of the x-bit ESDS will be used and both DES and UES are shifted according to the sequence. Each of the twenty-bit "blocks" that make up the illustrated DES and UES are shifted according to the sequence. The exemplary twenty bit ESDS is used for DES and UES, which results in the following.

ESDS：06.16.09.13.01.03.19.12.18.14.05.08.07.10.02.17.20.11.15.04

This shifting operation is based on the above-described sequence reflecting the movement of each character. In the above example, the first character in the DES or UES would move to position six, the second character would move to position sixteen, the third character would move to position nine, and so on.

3. As the example illustrated in figure 6, after DES and UES have been shifted with respective ESDS based on the ESDSREF, each sequence may then be further shifted by using one of the five CSDSs, as indicated by the CSDSREF. For example, using one of the three example CSDSS's for the twenty-bit DES and UES, reflecting one of three as indicated by the value "1" in CSDSREF, the DES and UES would be shifted as follows:

● if the CSDSREF is "1", the first ("6") of the three illustrated twenty-bit correlated CSDSs will be used. Each character for DES and UES will move forward six characters to reflect the change, moving the first character of DES and UES and further eliminating the risk of password leakage.

4. If a new DES and UES has now been constructed, the following changes will be made:

● the ESDSREF will add + 1. If the result is greater than the total number of ESDSREF, it will be set to "1";

● CSDSREF will add + 1. If the result is greater than the total number of CSDSREF, it will be set to "1";

● CSREF will add + 1. If the result is greater than the total number of CSREF, it will be set to "1" (note that for additional complexity, CSREF may simply cycle between 1 and the total number of UCS and DCS for each login to avoid any possibility of a password being tried and a sequence being constructed);

● ESREF will be set to "01"

The above example relates to ESDS, which is the same length as DES and UES. If DES and UES are, for example, one thousand bits and the ESDS are one hundred bits each, then different ESDS are used to shift blocks of each one hundred bits in DES and UES before the final CSDS related shift process.

As will be appreciated, in order to maintain code synchronization between the authentication device 106 and the authentication server 116, a shift process needs to be synchronized on the authentication device and the authentication server. After synchronization, the authentication device 106 will wait for the next user authentication.

When the shifting process has been completed and the user logs in next time, the process is located using the following data:

● DES and UES will both be shifted and aligned with the new start character at position 1;

● CSREF will be set to a value between 1 and the total number of CSREF that will reference the appropriate UCS and DCS codes used to authenticate the service authentication code and encode the user's PIN; and is

● the next service authentication code presented on the authentication server resets the last two characters to "01" to indicate that the first ten bit block of DES and UES is used.

Once the shifting of DES and UES has been completed, the CSDS can shift the entire sequence as a means of reordering start point for the first ten bit block of each sequence. This will lead to the following cryptographic complexity.

1. Assuming that a four-digit PIN is encoded into a four-digit password and only four digits are used in each ten-bit block, if a skilled cryptographer can obtain all the first one hundred logged OTPs (based on a one thousand UES), they will only obtain 40% of the characters in a one thousand bit sequence. It can be reduced to only 20% in the case of only two characters for the PIN. For example, "3553".

2. This would mean that each number used in each encoded password could be any number used in the corresponding service authentication code. Thus, nothing is shown for the first one hundred logins.

3. After all one thousand characters have been complexly shifted, with the ESDS corresponding to ESDSREF, a new starting point will be defined by the CSDS corresponding to CSDSRE, thus effectively providing a new one thousand bits UES.

4. If the cryptographer can then obtain each of the next hundred OTP, they will also only obtain 20% -40% of the data on which the trial sequence is based. However, these additional one hundred OTPs may be built for different service authentication codes, and therefore any "possible" relationship will be lost between the two OTPs, and the complexity is therefore significantly magnified.

5. Theoretically, assuming the clerk did not get anything from the previous hundred OTPs, they would then try and observe the second 32 x 10¹⁵³⁰The UES work on each of the 360 ten thousand possible service authentication code sequences, where they would have to try each of a thousand digits as a starting point to determine which of the 360 ten thousand possible service authentication codes has been reflected for the first 32 x 32 code used¹⁵³⁰The same PIN of the UES of the bits. Unfortunately, they will also have to cope with at least twenty-seven repeated UES characters (based on a one thousand bit UES), which will result in multiple false positives, and when they may think that it has been completed, the shift sequence will occur again, the service authentication code is also changed.

6. Thus, while it is conceptually possible to compute portions of previous UES and construct possible solutions and potential PINs, the data to perform such analysis must be historical and become obsolete each time a shift sequence occurs.

Example 4: resetting a user PIN

When the user 102 is unsuccessful in logging in three times, or may realize that they have forgotten their user PIN, the user will automatically engage in the Q & A function.

Then, the procedure is as follows:

1. if a user simply forgets their user PIN and wishes to reset them, they will be required to enter their activation code. If they have failed several times (e.g., three times), then the activate code has been provided.

2. The activation code will be sent to the authentication server 116 to present the service authentication code to the user 102.

3. The user 102 will verify the service authentication code and be prompted to enter a randomly selected PIN (selected by the authentication server 116) into their authentication device 106;

4. they will then enter the encoded PIN and submit it to authentication server 116;

5. if the PIN proves that they are using the correct authentication device 116, the user 102 will be presented with a Q & A process;

6. successful completion of the Q & a process will result in the user 102 being required to select new user PINs which are then locked by the authentication server 116 for a predetermined period of time, such that if the user 102 is not the one who is accessing the Q & a process, the period of time is sufficient for the user 102 to contact the authentication device issuer or publisher that they are attempting to access.

7. Failure of the Q & a process should result in the user 102 having to access a trusted source in order for them to be able to start their authentication device again and for this one hundred points will be required to be detected.

Example 5: application of authentication method or device in multi-service environment

In one embodiment, users 102 may use their individual authentication devices 106 to access a variety of remote services based on trust relationships expressed as different trust levels, or trust categories. For example, the authentication method may be based on the following trust categories:

trust level 3:

the trust level 3 category may be retrieved when the user 102 has completed a "100" point test, which may be authenticated by authorized personnel at a bank or suitable exit.

If the user 102 is novice to the e-banking industry and has visited a branch to obtain their authentication device 106, the category of trust level 3 can be immediately taken, at which point the bank will transmit a one hundred point check and register the user with the remote service at the branch.

Alternatively, if the user 102 wishes to take the category of trust level 3 and they already have an authentication device 106, the user 102 will have to visit a bank or suitable trusted source in order to complete the one hundred point detection, at which point the user details can be updated on the authentication server 116.

Trust level 2:

the category of trust level 2 may be implemented when a user 102 registers their authentication device 106 via a service that they have obtained early credentials in a secure manner.

For example, the current user ID and password for the e-banking industry would be provided to the user 102 simply by mail or in a secure manner at the branch office. Thus, the user 102 will log into a confidential service for which identity management was previously considered controlled.

Similarly, information used to authenticate a credit card holder when not using a credit card, such as online or phone shopping, would be considered a category of trust level 2, since the user can only provide various unique codes on the card.

Trust level 1:

if a user acquires an authentication device 106 for a remote service, such as an online auction website, the initial registration of the user 102 will be a simple self-registration process without any identity management or control. Thus, while the authentication device 106 will add additional security to all transactions that are sequentially conducted by the individual for which a particular service is intended, there is no tool to verify their true identity.

Similarly, if the user is to visit a bank or a trustworthy source, the user 102 may be promoted to trust level 3, and thus, one hundred point detection will be performed-against the above-described wording and circumstances used.

It is important to note that the secondary identifier agreed upon between all service providers will have to be sufficiently unique to enable the user 102 to be securely associated to the respective account. For example, the above-mentioned online auction website would have to select a tool by which one hundred point detections would be securely linked to an account, and similarly, a bank would need to define some form of identifier that is considered a suitable tool by which to authenticate a user, such as a cash withdrawal card account or the like.

Trust level 3V:

a fourth trust level may also be defined that would not be achievable by one process. Such a trust level may be achieved when the user 102 has completed a predetermined number of authentication cycles without having their authentication device 106 being asked or used for fraudulent purposes. This approach would provide an advanced trust relationship that would be considered to be stronger than the category of trust level 2, but not to the category of trust level 3. However, it applies that it can be considered to be applicable to a collective service for which special means are used to update the user status to a trust level of 3V.

An online authentication report may be generated when the authentication device 106 has exceeded a predetermined amount of use of a particular service. Each service may then determine how much they will be prepared to "trust" the corresponding user 102 based on their activity with the remote service 104.

When the user 102 has been accepted by all services for which a predetermined number of uses are transcended by them, a forward boost to trust level 3V will be considered appropriate to allow the user to access the trust level 3 service that has agreed to accept trust level 3V users even though they have not completed all one hundred point detections.

It is envisaged that embodiments of the present invention using a trust model of the type described above may further provide virtual identity management, and therefore the use of this system may result in trust of a given user identity based on the legitimacy of the transaction and the predetermined amount of the transaction.

Example 6: interoperable authentication device trust level registration

The following sections illustrate the registration process for each trust level and focus on the processes associated with implementing the trust level 1 state.

Given that there are many variations and methods to obtain an authentication device 106, such as a post office, consumer electronic storage, etc., that do not necessarily result in the authentication device 106 being provided in a secure manner, embodiments of the present invention provide a defined process of registering and, accordingly, providing an appropriate level of trust involving a third party remote service provider. Basically, a user with an authentication device at trust level 1 will not be able to access higher level services.

Category of trust level 3:

the user can achieve trust level 3 in four ways:

(i) the new user 102 wishes to be able to access services provided by a trusted source such as a bank, government agency or post office;

(ii) the current user 102 has performed a one-hundred point test with a trusted source, as described above ("100 point test");

(iii) in the event that the user loses the authentication device 106, where the authentication device 106 has been used by the user 102 to access a service having a unique identifier, the user 102 may be authenticated by any registered and trusted authentication device service according to the identifier; and is

(iv) The Q & a process cannot be completed at the user 102 and he has forgotten their PIN and the answer to their own question.

Each of these different approaches will now be described in detail.

(i) New user

To immediately implement the trust level 3 category, the user 102 would have to register itself with a trusted online service, such as a bank, government agency, or post office.

Users 102 may access trusted services, such as bank branches, and require registration for their services.

The branch agent will then need to complete the "100" point detection and authentication registration process.

The "100" point detection is a standard process, but may be represented graphically on the certification management console to ensure that the branch agent can complete all required steps. If the "100" point check has been completed to verify the identity of the user-for this reason, the trusted source will have to have an account associated with the individual, e.g. a bank account-the branch agent can then register the user's authentication device 106 by following the registration procedure.

This would require entry of the required ("noted") authentication device 106 activation code and entry of the service authentication code to enable the PIN to be selected. If the process has been completed, the input can be digitally "signed" by the branch office agent, after which the user 102 can access the corresponding online service by means of his authentication device 106 in trust level 3 state.

If agreement has been previously obtained between the authentication apparatus 106 and the trusted service provider, a unique identifier, such as a cash card withdrawal account number or the like, would have to be entered. This would be a secondary identifier in addition to the "100" point detection, which would be required if the user 102 lost their authentication device 106 or forgotten an answer to their personal question, and the user had to access another trusted source to obtain a new device or have their account reset (defined in iii and iv below).

The trusted source that booted the initial registration and provided the authentication device will also become the user's primary service provider.

ii) "100" Point detection

In case the user 102 who has registered the authentication apparatus wishes to obtain a trust level 3 status, they need to access a trusted source, such as a bank, a government agency or a post office, etc., where the authentication apparatus is registered.

If a trusted source has a service for which the user has registered, they will be able to complete the "100" point detection process since they can verify the "100" point detection against the user's account with the source. This can occur when the user 102 has previously registered online as a trust level 2 category and has subsequently personally visited the remote service provider to change their trust level category.

The agent will be able to access the user's authentication device account through the agreed service identifier (e.g., cash withdrawal card number, etc.) and/or activation code of their authentication device. The authentication server will then summarize all the requirements needed to implement the "100" point detection.

The agent may then ask the user to successfully authenticate himself to the authentication device based on the service authentication code issued by their authentication device and authentication server by providing a PIN once. If the process has been completed, the user will be registered as a trust level 3 user.

If the user 102 has accessed a trusted source that they do not have an account, the source may still perform a "100" point detection.

The user 102 will in this case provide a unique identifier, as described in detail between the authentication device 106 and the remote service 104 to which the user 102 has registered an account the agent can then log into the authentication device management console, search for appropriate services, and verify that the information held by the user, e.g., cash withdrawal cards, driver's license content, etc., is registered for the corresponding service.

If this step has been completed, the agent can then ask the user to enter their authentication device DPIN as a further verification tool, and then verify the details by digitally signing the input. The user will then get trust level 3 status.

iii) loss device

In the event that the user 102 loses their authentication apparatus 106, they can obtain another one from a trusted service for which they have registered use of their authentication apparatus 106, or they may access another registration service — which would have to be a trusted source such as a bank or post office.

In order for their authentication device 106 to initiate a service, the agent providing the new authentication device 106 will have to perform a "100" point check and verify against their own database the unique identifier of the user with which the user has registered their authentication device 106 or ensure that the identifier matches another remote service 104 that registered the user 102.

If the user 102 is acquiring the authentication device 106 from a trusted service for which they have registered their authentication device 106 for use, the broker can perform a "100" point check and verify the unique service identity. However, the reboot process on the authentication device management console will require a new device activation code at all that is submitted along with the unique identifier so that the authentication server 116 can transfer the user details from their original authentication device 106 to the new authentication device and then cancel the original authentication device.

Assuming that the user 102 merely loses their authentication device 106, they will also be required to submit their user PIN to the authentication server 116 as an added identification tool.

Assuming that the user 102 launches their authentication device 106 again to the trust service with which they have registered their authentication device 106, the restart can be instantaneous and the user 102 can effectively use the authentication device 106 to access all services that they have registered earlier.

Additionally, if the necessary 100 point detection has been completed, the trust level category will be moved to trust level 3.

Additionally, if the authentication device 106 is adapted for sale through a retail outlet, the user 102 may have purchased a new authentication device 106, and thus the aforementioned agent may use any authentication device 106 purchased by the user. The authentication service will detect when the activation code is entered to enable the user 102 to ensure that the authentication device 106 has not been used by others or has been deactivated, thereby preventing a lost or stolen device from being used again.

If the user 102 accesses a trusted service that they are not registered, the agent will perform a "100" point check and verify the unique identifier of the service that they have registered. Assuming that the user 102 simply loses their authentication device 106, they will also be required to submit their user PIN to the authentication server as an added validation tool.

They can then register and restart the authentication device.

iv) failure to complete Q&A

In case the user 102 is unable to complete their Q & a, they need to access the services trusted by the registered authentication device.

The trusted service can only perform a "100" point check and verify the identity of the user 102 with the authentication service management console.

As described in (iii) above (i.e., the lost device), if the user 102 accesses a trusted source that provides services that have registered their authentication device 106, the agent can perform a "100" point detection and restart the authentication device 106 by using the authentication device's activation code, service authentication code, and a new PIN selected for the user.

If the user 102 accesses a registered authenticated device trusted source that provides an online service that the user 102 has not registered with, the trusted source can perform a "100" point check and verification against the unique authenticated device service identifier. These are put together enough to ensure the identity and their relationship to the remote service that has provided the identification. As a result, the user 102 may reboot their new device.

Additionally, when the user 102 logs in again for the first time, they will be asked to submit new questions and personal answers, assuming they have forgotten what was the first time.

Example 6: authentication device processing

The following examples illustrate various ways in which users 102 may register their authentication devices 106 through primary and secondary services, and illustrate procedures that they typically need to follow in order to ensure continued use of the authentication devices 106. In embodiments, these processes may include, but are not limited to:

1. configuration of the authentication device;

2. registration of the authentication device;

3. registration of multiple devices; and

4. a user requirement to authenticate the device;

each of the above processes will now be described in more detail.

1. Configuration of authentication device

This section summarizes the ways by which a user can register or acquire an authentication device according to the category of trust level.

Trust level 3:

as explained above, in an embodiment, the only way for the user 102 to obtain the instant trust level 3 is to obtain their authentication device 106 through the personal presence at the trust source and follow the "100" point detection.

However, instead of "picking up" the standard authentication device 106, the user 102 may request that the authentication device 106 be provided to them in one of a number of ways, such as:

1. to a mobile device, such as a mobile telephone. This would require the user 102 to provide their mobile phone details when registering themselves, or when acquiring a new authentication device (which has lost their original device). When provided in this manner, the authentication device 106 will be provided as a "software device" which should first be "identified" to the user so that they can select their user PIN during registration. Upon receiving the authentication device 106 by SMS or the like, the user 102 already has a user PIN to log in to the authentication device 106; or

2. For a user 102 who wishes to download a new software device to another medium, such as an HP iPAQ handheld computer, the user 102 can access a library of downloadable software devices or transfer an authentication device 106 by linking the re-registered authentication device 106 to an individual. A person assisting a user in registering their authentication device in this way may provide a link to the software device by means of an activation code, perhaps using a standard single-use available password selected by the user. The user can also select their authentication device PIN. This would allow the user 102 to access their software device when the user 102 logs in to the authentication server 116 sequentially using the activation code provided to them and the standard one-time password they have selected, which they can then download into their HP iPAQ or similar medium. Since the PIN has been selected for the device, the user 102 is the only person that can use the authentication device, and the category of trust level 3 will not be breached.

Trust level 2:

the following focuses on how the user 102 will acquire the authentication device 106 in a trust level 2 relationship:

● when the user 102 has logged into the corresponding service using pre-stored credentials such as a user ID and password, the user 102 may physically transmit the authentication device in the form of a mail after having requested the authentication device. Similarly, the user 102 may request the authentication device 106 based on a unique pre-stored identification such as credit card content, which will then only be mailed to the address that is present on the database of the remote service for that individual;

● after having signed up to the service using pre-stored credentials or pre-stored identity criteria provided, such as credit card content, the user 102 may request that the "software device" be sent to the user 102 via SMS; or

● the user 102 may request to download the authentication device 106 so that they can install it on a medium of their choice such as the HP iPAQ.

In all the examples mentioned above, the authentication service registration process is the same as the process the user will handle with the authentication device, regardless of the medium on which the authentication device is located.

Trust level 1:

in order to obtain an authentication device 106 for the trust level 1 category, no control is necessary if it is assumed that the authentication device merely considers the user 102 to be who they say. This level of control only prevents an account from being compromised once it has been established, provided that the user is able to self-register and enter any personal content.

As described above, at any time, the user 102 can move from a Category relationship of Trust level 1 to a Category relationship of Trust level 2 by registering their authentication device with pre-stored credentials from a trust source. Similarly, the user may also move to a category relationship of trust level 3 by accessing a trusted source and completing the "100" point detection.

Note that in any event, nothing prevents any user 102 from purchasing an authentication device 106 from a retail channel. However, the trust level relationship will depend on the registration process.

It is also important to note that while the class relationship of trust level 1 already exists, the remote service may employ authentication means assigned security tools that are valuable for improved trust level user classification. However, since trust level 1 category relationships are primarily based on self-registration and trust, consent must be obtained between the remote service providers. Thus, content provided by any user may be fraudulent and may not be worth relying on the classification of the trust level 2 category. In fact, the trust level 3 class can only be implemented with secure adoption of an increased trust level classification outside of the trust level 1 class.

From the above, it is clear that the greatest interest of a trust level 1 service provider is to supplement support for authentication devices issued by at least trust level 2 category relationships.

2. Registration of authentication device:

the following sections outline examples of registration procedures that users follow during registration of their authentication devices, and the following sections also outline the reliance on the user's trust level categories.

Registration of trust level 3:

when the user 102 accesses a trusted service provider, such as a bank or post office, the user 102 will follow the standard registration process regardless of whether they eventually stop using the authentication apparatus 106 medium. An example of this process is described below:

1. the user 102 will indicate that they wish to access the trusted service provider's online service. In this example, we have used an online banking service;

2. the bank agent will complete the "100" point detection and build a definitive link between the individual and the account the individual holds for the remote service provider.

3. The bank agent then authenticates to the authentication service manager and registers the user in a number of different ways, depending on the authentication device medium selected by the user 102;

4. if the user 102 has chosen to employ a physical device, the bank agent will enter the contents of the authentication device activation code and unique identifier, which will be required later if the user loses their authentication device. The user 102 will then be required to enter a service authentication code issued by the authentication server 116-to verify the entity device-and will then be required to select a PIN. They will then be able to access the remote service as trust level 3 users. Note that they will have to go through the Q & a process when they first log in;

5. if the user 102 wishes to have the authentication device 106 communicate to their mobile phone, the agent will need to link their mobile phone number to the activation code derived from the authentication server. This will also enable the user to select their user PIN online so that when the software means is then transferred by the authentication server to their mobile phone they can log in using the user PIN they have selected. Note that they will also be prompted to complete the Q & a process;

6. if the user 102 wishes to obtain an authentication device as a software device to install on their PDA or HP iPAQ or the like, the bank agent will again obtain an activation code that will link to the individual. In addition to requiring them to enter their user PIN, the agent will also require a single standard password. This will be sent to the user along with their activation code so that when they subsequently log in, they will be able to access the authentication device service to access and download their authentication device. The authentication device will then only work with the correct PIN selected by the user and they will be forced to complete the Q & a process.

Trust level 2 registration:

in order to register a user in the trust level 2 category, a setting must be made that the user 102 is able to obtain the authentication device 106 in whatever way is deemed possible, whether it is by mail, picked up from a retail channel or from their service provider, etc. By adopting the method to register the authentication device, the trust level 2 category of the user can be determined.

The key to the trust level 2 category is that the user 102 has given confirmation credentials that are only available to them. Such as pre-stored credentials for accessing electronic banking services or credit card content. It is important to note that such credentials are provided to the user under some controlled delivery mechanism. However, from an authentication service perspective, it cannot be assumed, though possible, that the credentials fall into the hands of the appropriate person.

Once the authentication device is registered, the user 102 will have to log into a pre-stored trust level 2 service, such as an online banking service, or the user 102 will ensure that they have information unique to them, such as credit card content or the like.

A particular trust level 2 category service may pass a user's registration through an authentication server if a unique credential has been logged in or provided.

Upon returning the service authentication code, the authentication server 116 will request the user's device activation code. This service authentication code has the dual purpose of enabling the user 102 to be confident that they are communicating with the authentication service and ensuring that the authentication device 106 is synchronized with the authentication server 116.

If the user 102 has been assured that they are communicating with the authentication service, they follow the standard registration process and they will select a PIN and complete the Q & A process. Once these tasks are completed, the authentication service will return a remote service that controls the user to which their authentication device is being registered. The remote service 104 will then return a unique identifier by which the user can be verified when they wish to change their trust level category, or when they have lost the authentication device 106 or have been unable to answer their own Q & a.

Trust level 1 registration:

for services that require self-registration, such as an online auction website, no tools are required to ensure that an individual is who they say.

However, since the current threat makes it possible for all accounts that use simple user IDs and passwords for internet transactions to be compromised, the authentication service will ensure that such accounts are only accessed by individuals and their corresponding authentication devices.

For the trust level 1 category to self-register, it must also be assumed that the user 102 can obtain the authentication means in any way deemed possible, whether it is by mail, picked up from a retail channel or from their service provider, etc. Then, by registering the authentication apparatus in this manner, the trust level 1 category of the user can be determined.

The key to the trust level 1 category is that the user 102 will not provide any prior tools to ensure their authenticity and therefore their identity cannot rely on the transactions and services associated with the trust level 2 or 3 categories.

Once the authentication device 106 is registered, the user 102 will have to log into a pre-stored trust level 1 category service, such as an online auction website, by using credentials initially obtained during self-registration. Further, at this point they also need a unique identity in the form that the trust level 1 category service will consider all users that will perform on it. The reason for this is that subsequent reboots can be made and the trust level categories updated at the trusted source.

If the old credentials have been used to log in or the new user self-registration process has been completed, then the particular trust level 1 class service will pass the user 102 through the registration of the authentication server.

Upon returning the service authentication code, the authentication server 116 will request the user's device activation code. This service authentication code has the dual purpose of enabling the user to be sure that they are communicating with the authentication service and ensuring that the authentication device is synchronized with the authentication server 116.

If the user 102 has confidence that they are communicating with the authentication service, the user 102 will follow the standard registration process and they will select a PIN and complete the Q & A process. Once these tasks are completed, the authentication service will return a remote service that controls the user to which their authentication device is being registered. The remote service 104 will then return a unique identifier by which the user can be authenticated in the future.

3. Multi-device registration:

if their authentication device has been registered for a trust level service relationship, the user 102 can benefit from using their authentication device 106 for authenticating all other services in the service "family". However, the remote services 104 to which they can register will depend on their current trust level status and the tools they authenticate themselves.

Trust level 3 status:

if the user 102 has registered as a trust level 3 user, they will be able to register all services in the authentication service "family".

In any case, the user 102 will be able to select registration by their authentication device 106. The remote service they wish to register with can then request an activation code to them and will place a call to the authentication service to build their trust level category. If the user is not a trust level 3 user, an alternative procedure must be followed (see below).

Once the user 102 is authenticated as a trust level 3 class user, the authentication server 116 can ensure that they are the legitimate owner of the authentication device 106 by providing a service authentication code and requesting entry of their user PIN. Successful completion of this step will enable the authentication device 106 to return a code to the remote service that the user 102 is attempting to register with, thereby enabling the completion of the appropriate content that meets the requirements of this particular service.

Once the registration process of the remote service is completed, the remote service should provide the unique identifier required by the authentication server for subsequent use, so that the user can be re-authenticated in the event that the user loses their authentication device or fails to answer their own questions.

Although the user may enter fraudulent content at this point, they are assumed to be trust level 3 category users and any future actions taken using the authentication device will be traced back to legitimate users.

Trust level 2 status:

even if the user 102 is a trust level 2 class user, they will still need to obtain credentials directly from the trust level 2 class service they are meant to register with, or need to have unique credentials such as a credit card.

If such content is sent in the form of mail, as is the case today, users can log in using these credentials and then register their authentication device. On the other hand, if the user decides to access the remote service they intend to register with, they will be able to do so on the site as a result of which, as explained earlier, their trust level status will change to trust level 3.

Assuming that the user 102 has transferred credentials or has pre-stored credentials for a trust level 2 service, they will be able to log in using such credentials and then request to register their authentication device.

The remote service they wish to register with can then request their activation code and then pass control to the authentication server for completion of the registration. However, in this case, the authentication server 116 will not follow the initial authentication device registration process, since if it is set that the user is already registered, they need only verify their identity by providing a service authentication code and authenticating the user's PIN.

The authentication server 116 can then return a successful code to the class service of trust level 2, which will then provide the unique identifier required by the authentication server 116 for subsequent use, thereby enabling the user 102 to re-verify in the event that the user has lost their authentication device or has been unable to answer their own questions.

Trust level 1 status:

to register a device with a trust level 1 class service, the user 102 can use pre-stored self-registration credentials that they already have, or can complete the self-registration process for a remote service. Either way, the user 102 will indicate that they wish to register their authentication device 106 with the remote service 104. All of these approaches limit the fact that the account is not compromised by current threats and will limit the use of the account to others with whom the authentication device can be registered.

The remote service 104 to which they wish to register can then request their activation code, and then pass control to the authentication server 116 for completion of the registration. However, in this case, the authentication server 116 will not follow the initial authentication device registration procedure because if it is set that the user is already registered, they need only verify their identity by providing the service authentication code and verifying the user's PIN.

The authentication server 116 may then return a successful code to the trust level 1 class service, which will then provide the unique identifier required by the authentication server 116 for subsequent use, thereby enabling the user 102 to re-verify if they have lost their authentication device 106 or have been unable to answer their own questions.

The user obtains the authentication device:

in an embodiment, there are two main devices through which the user 102 can obtain or obtain the authentication device 106, namely:

1. this can be any trust level service in the authentication service 'family' or any retail channel where it is desirable to make such devices available to the public; and

2. "software" authentication device — a software device may be downloaded from the authentication server 116 or from a corresponding service. The use of such a device would mean that no substantial cost would be incurred immediately, but such cost would be spread throughout the process of the user making the request for the software device.

Example 7: authentication device linked to current process

The authentication device 106 may link to the current process by using a current service such as "Verfied by Visa" or "MasterCardSecureCode".

In the event that the user 102 wishes to register their authentication device 106 with such a service for use, the user 102 will be able to access the remote service based on the fact that they have trust level 2 credentials, as is the current practice.

Currently, these services are based on trust level 2 credentials available on credit cards. However, if user 102 registers their authentication device 106 as an additional step, remote service 104 may enable the process to be implemented as a payment instrument without having to enter a fixed password online.

While services such as "Verfied by Visa" and "MasterCard SecureCode" have been introduced to avoid the need to enter credit card content online, this type of service still goes through a "bootstrapping" and/or push-to-log process to obtain a user password and thus is susceptible to fraudulent online payment transactions.

Thus, the remote service is able to provide the user credit card content to the authentication device as a unique identifier. When the user 102 chooses to pay using the authentication device 106, the remote service 104 will call the authentication server 116, which then authenticates the payment with the single user PIN.

In view of the foregoing, it can be appreciated that the present invention provides an authentication method and apparatus adapted to assist a user 102 in verifying that he or she is communicating with a remote service and/or entity with which they are transacting. The authentication method and apparatus of the present invention represents an engineered feature of anti-mirror and anti-social, since current threats make it possible for users to be fooled into revealing their personal credentials through mirror websites, where "inducers" and fraudsters make users believe that they are communicating with legitimate entities.

In addition, by providing the user 102 with a unique single-time service authentication code, the remote service 104 and/or entity effectively authenticates the user prior to conducting any commercial online transaction.

With reference to the foregoing, it can be appreciated that an authentication method and/or apparatus in accordance with embodiments of the present invention provides a three-factor authentication method and/or apparatus in that the following unique steps must be successfully performed in order to authenticate and/or verify the identity of the user to be validated.

1. A valid authentication service code is provided from the remote service 104 or other entity where the user 102 is wishing to verify his identity. In an embodiment, a valid authentication service code will enable operation of the authentication device 106, and an invalid authentication service code will disable operation of the authentication device 106;

2. the user 102 enters their own unique user PIN into the authentication device 106, which PIN will then be encoded by the authentication device 106 and displayed for entry or transfer to the remote service 104 or other entity that the user 102 is authenticating; and

3. the encoded user PIN is entered into a remote service and/or entity.

In addition, the authentication apparatus 106 according to an embodiment of the present invention may be provided in a software form so as to be installed on a mobile phone, a PDA, or the like according to a user's selection.

Preferably, the authentication device 106 according to embodiments of the present invention does not have to be "seeded" prior to dispatch, as the user can activate the authentication device at registration and the authentication device remains unused until registered with pre-stored credentials provided by the remote service to which they are registering the authentication device.

As described above, the authentication device may be integrated with multiple currently existing verification and authentication processes, otherwise, multiple devices would need to be employed. With a simple enrollment process, the user would only need to execute a single authentication device in order to perform many functions that require security and that may currently be problematic, such as telephone banking, online shopping, manual identification, and paper check verification, among others.

Additionally, the authentication device product may allow for progressive identities based on pre-stored trust relationships driven by the authentication process. In particular, user confirmation may be a gradual process rather than an instantaneous process. It is envisaged that this process may bring significant economic benefits, thereby compensating for the current inhibition of such changes that require immediate verification of the identity of the user in order to operate with alternative products.

As mentioned above, the Q & a feature, as provided by embodiments of the present invention, is supplemented by the fact that users will not be able to access their Q & a unless they physically possess their authentication device. Thus, the tools to answer questions further improve the security of embodiments of the present invention, as the user will not be able to complete the Q & a process without the use of an authentication device.

It is also envisaged that the authentication server also enables users to determine when their authentication devices can be used and thus provides each user with a practical and unique open time. Thus, in one embodiment, a user may determine an "open time" for using an authentication server. According to this embodiment, outside these times, login cannot be performed. In the case where the user wishes to change time, they will have to wait until a predetermined open time to do so. Thus, control is completely user dependent.

Finally, it is to be understood that there are numerous other variations and modifications of the configurations described herein which fall within the scope of the present invention.

Claims (31)

1. A method of authenticating a remote service to a user via a communications network, the method comprising:

the remote service obtains a service authentication code generated by a code generation algorithm based on a first key;

transmitting the service authentication code to the user via the communication network;

receiving or inputting the service authentication code into an authentication device associated with the user;

the authentication device generating an expected code value using the same code generation algorithm based on a second key and then comparing the expected code value with the service authentication code; and is

In response to the comparison and in the event that the expected code value correlates with the service authentication code, the authentication device generates a response indicating the remote service authenticity to the user.

2. The method of claim 1, wherein the remote service comprises an e-commerce service.

3. The method of claim 1, wherein the e-commerce service comprises an internet commerce service.

4. The method of claim 1, wherein the service authentication code is generated by an authentication server communicatively connected to a server hosting the remote service.

5. A method according to claim 1, wherein the first key is obtained by indexing a user-provided code into a database containing codes for each authentication device that has been registered for accessing the remote service, and the first key associated therewith, thereby obtaining the first key associated with the user-provided code.

6. The method of claim 5, wherein the user-provided code uniquely identifies the authentication device.

7. The method of claim 1, wherein the generating of the service authentication code comprises: the first key is encoded to provide a single usable authentication code.

8. The method of claim 7, wherein each instance of the code generation algorithm uses a first pseudo-random code sequence and a second pseudo-random code sequence, the second pseudo-random code sequence having a sequence length that is the same as the sequence length of the first pseudo-random code sequence.

9. The method of claim 8, wherein the first pseudo-random code sequence comprises a sequence of single-occurrence characters forming a character set from which the first key is derived, such that the first pseudo-random code sequence comprises characters of the first key.

10. The method of claim 8, wherein the second pseudo-random encoding sequence comprises an arrangement of characters from a different set of characters than the first key.

11. The method of claim 8, wherein a code generation algorithm for producing the service authentication code or the expected value, respectively, comprises:

sequentially identifying the positions of characters in a first pseudorandom encoding sequence corresponding to the characters of the first key or the second key;

mapping the positions of the identified characters in the first pseudo-random code sequence to characters of a second pseudo-random code sequence having the same sequence positions to provide a set of characters from the second pseudo-random code sequence; and is

Arranging the character set of the second pseudo-random code sequence in the order of identification, thereby forming the service authentication code.

12. The method of claim 8, wherein whenever a service authentication code is generated, different first and second pseudo-random encoding sequences are used to reduce the likelihood of repeated generation of the same service authentication code.

13. The method of claim 1, wherein the responding comprises: activating the authentication device to generate a user authentication code for authenticating the user to the remote service.

14. The method of claim 1, wherein the second key is stored in a memory carried by the authentication device, such that the user is generally inaccessible.

15. The method of claim 1, wherein the service authentication code includes an identifier for synchronizing a code generation algorithm that produces the service authentication code with a code generation algorithm that produces the desired code value.

16. The method of claim 1, wherein a code generation algorithm for generating a service authentication code based on the first key and a code generation algorithm for generating the expected code value based on the second key use synchronized code sequences that generate the service authentication code and the expected code value based on the first and second keys, respectively.

17. The method of claim 16, wherein the encoded sequence is modified each time a service authentication code is generated.

18. A method of mutually authenticating a remote service user and a remote service via a communications network, the method comprising:

the remote service obtains a service authentication code generated by a code generation algorithm based on a first key;

transmitting the service authentication code to the user via the communication network;

receiving or inputting the service authentication code into an authentication device associated with the user;

the authentication device generating an expected code value using the same code generation algorithm based on a second key, and then comparing the expected code value with the service authentication code;

in response to the comparison and in the event that the expected code correlates with the service authentication code, the authentication device generating a user authentication code value using a code generation algorithm based on a third key;

transmitting the user authentication code to the remote service via the communication network;

the remote service or other service obtaining a second expected code value generated based on a fourth key and then comparing the second expected code value with the user authentication code; and is

In response to the comparison and in the event that the second expected code value correlates with the user authentication code, the remote service allows the user further access to the remote service.

19. An authentication apparatus for providing a response indicating to a user of the authentication apparatus the authenticity of a remote service based on a service authentication code provided by the remote service, the authentication apparatus comprising:

an input device for receiving or inputting the service authentication code, the service authentication code being generated using a code generation algorithm based on a first key;

generator means for generating a desired code value using the same code generation algorithm based on the second key;

comparator means for comparing the expected code value with the service authentication code; and

response generator means for generating a response indicative of the authenticity of the remote service in dependence on the comparison of the expected code and the service authentication code.

20. Apparatus according to claim 19, wherein each code generation algorithm uses a first pseudo-random code sequence and a second pseudo-random code sequence, the second pseudo-random code sequence having a sequence length that is the same as the sequence length of the first pseudo-random code sequence.

21. The apparatus of claim 20, wherein the first pseudo-random code sequence comprises a sequence of single-occurrence characters forming a character set from which the first key is derived, such that the first pseudo-random code sequence comprises characters of the first key.

22. The apparatus of claim 20, wherein the second pseudo-random encoding sequence comprises an arrangement of characters from the same or different character set as the first key.

23. The apparatus of claim 20, wherein a code generation algorithm for producing the expected value comprises:

sequentially identifying the positions of characters in a first pseudorandom encoding sequence corresponding to the characters of the second key;

mapping the positions of the identified characters in the first pseudo-random code sequence to characters of a second pseudo-random code sequence having the same sequence positions to provide a set of characters from the second pseudo-random code sequence; and is

Arranging the character set of the second pseudo-random code sequence in the order of identification, thereby forming the service authentication code.

24. The apparatus of claim 20, wherein different first and second pseudo-random encoding sequences are used whenever a service authentication code is generated to reduce the likelihood of repeated generation of the same service authentication code.

25. The apparatus of claim 19, wherein the response comprises: activating the authentication device to generate a user authentication code for authenticating the user to the remote service.

26. The apparatus of claim 19, wherein the second key is stored in a memory carried by the authentication apparatus, such that the user is generally inaccessible.

27. The apparatus of claim 19, wherein the service authentication code includes an identifier for synchronizing a code generation algorithm that produces the service authentication code with a code generation algorithm that produces the desired code value.

28. The apparatus of claim 19, wherein a code generation algorithm for generating a service authentication code based on the first key and a code generation algorithm for generating the expected code value based on the second key use synchronized code sequences that generate the service authentication code and the expected code value based on the first key and the second key, respectively.

29. The apparatus of claim 28, wherein the encoded sequence is modified each time a service authentication code is generated.

30. A method of authenticating a remote service to a user via a communications network, the method comprising:

a user operating an authentication device to obtain a unique identification code associated therewith from the device;

transmitting said unique identification code to said remote service via a communications network;

the remote service obtaining a service authentication code generated using a code generation algorithm based on a first key, wherein the first key is obtained from a database containing identification codes of authentication devices registered for accessing the remote service by indexing the unique identification code into the database;

transmitting the service authentication code to the user via the communication network;

receiving or inputting the service authentication code into an authentication device associated with the user;

the authentication device generating an expected code value using the same code generation algorithm based on a second key and then comparing the expected code value with the service authentication code; and is

In response to the comparison and in the event that the expected code value correlates with the service authentication code, the authentication device generates a response indicating the remote service authenticity to the user.

31. A method of authenticating an identity and/or credentials of a second user to a first user via a communication network using a remote service, the method comprising:

the first user authenticating the remote service using the method of claim 1;

in the event that the remote service is authenticated as valid, the first user provides a user authentication code generated by an authentication device of a second user based on a key associated with or provided by the second user;

transmitting the user authentication code to the remote service via the communication network;

the remote service obtaining an expected code value generated based on a key and then comparing the expected code value with a user authentication code for the second user; and is

In response to the comparison and in the event that the expected code value correlates with the user authentication code, the remote service provides a response to the first user indicating the authenticity of the second user.