AU2008207334A1

AU2008207334A1 - Interaction process

Info

Publication number: AU2008207334A1
Application number: AU2008207334A
Authority: AU
Inventors: Michael Joseph Knight
Original assignee: Individual
Current assignee: Individual
Priority date: 2007-01-18
Filing date: 2008-01-15
Publication date: 2008-07-24
Also published as: WO2008086567A1

Description

WO 2008/086567 PCT/AU2008/000037 INTERACTION PROCESS Background of the Invention The present invention relates to a method and apparatus for performing an interaction, and in particular to performing a secure interaction using an interaction device. 5 Description of the Prior Art The reference in this specification to any prior publication (or information derived from it), or to any matter which is known, is not, and should not be taken as an acknowledgment or admission or any form of suggestion that the prior publication (or information derived from it) or known matter forms part of the common general knowledge in the field of endeavour to which this specification relates. 10 When performing interactions using a communications system such as the Internet, it is typical to implement some form of security protocol to ameliorate the risk of the interaction being compromised by a third party. This can include, for example, the use of identifiers, such as a username and password, to allow parties to be identified, as well as the use of encryption or the like, to prevent eavesdropping by third parties. 15 If the interaction is between a user and a second party, such as a corporation, security is normally controlled by the second party. In this instance, the second party provides the user with an identifier, so that the second party can subsequently use the identifier to authenticate the user. This allows the user to be identified by the second party, in turn allowing interactions to be performed. However, this has a number of drawbacks. For example, there is no mechanism for the user to 20 authenticate the second party, and hence, this leads to risk of third parties fraudulently imitating the second party to obtain the user's identifier, and hence to allow the third party to perform fraudulent interaction. Whilst this can be overcome, to an extent by the use of an intermediate trusted third party, this alone does not obviate all security issues. For example, there is no mechanism for the first party (the user) to ensure the security of the computer 25 or other communications device used by the first party (the user). Thus, the user could attempt to interact with the second party using a compromised device, which in turn can again allow third parties to fraudulently obtain the user's identifier, and/or monitor the interaction. This is a particular concern when the user is utilising a public terminal, such as in an Internet cafe or airport lounge. This is also of concern in corporations, such as banks, government agencies or the like where 30 "sensitive information" may be input/accessed. Typically in such corporate environments computer WO 2008/086567 PCT/AU2008/000037 -2 systems may be configured with software security to help retain the security of sensitive information, although in general such software based security mechanisms provide only limited security. Summary of the Present Invention In a first broad form the present invention provides a method of performing a secure interaction, the 5 method including, in an input device: a) performing a checking operation using first information, to thereby confirm input device integrity; b) providing second information received from a user, to a gatekeeper, the gatekeeper being responsive to the second information to: 10 i) perform authentication; and, ii) establish communication between the input device and a service provider in response to a successful authentication; and, c) communicating with the service provider in accordance with user input to thereby perform the secure interaction. 15 Typically the input device is connected to an identity device, and wherein the method includes, in the input device, performing the checking operation at least in part using information provided on the identity device. Typically the method includes, in the input device: a) receiving the first information from the user; 20 b) accessing first data from a first store at least partially using the first information; and, c) in an internal processing system, using the first data to confirm input device integrity. Typically the first data is stored as encrypted first data, and wherein the method includes, in the internal processing system, decrypting the first data using the first information. Typically the method includes, in the input device: 25 a) accessing an algorithm from a store; b) generating a first key at least in part using the first information and the algorithm; and, c) decrypting the first data using the first key. Typically the method includes, in the input device: a) accessing second data from a second store; and, 30 b) in the internal processing system, comparing at least some of the first and second data to thereby confirm input device integrity.

WO 2008/086567 PCT/AU2008/000037 -3 Typically the input device is connected to an identity device via a connection, and wherein the method includes, in the input device accessing at least one of first and second stores via the connection. Typically the method includes, in the input device, updating at least one of a sequence number and an executable file stored in the identity device. 5 Typically the method includes, in the input device, receiving at least one of an updated sequence number and an updated executable file, from the gatekeeper. Typically the method includes, in the input device: a) authenticating the identity device; and, b) performing the checking operation in response to successful authentication. 10 Typically the method includes, in the input device: a) checking the integrity of the identity device; and, b) generating an indication of the integrity using an indicator. Typically the input device is coupled to a computer system, and wherein, the method includes, in the input device and in response to confirming the integrity of the input device: 15 a) determining a service list from a store; and, b) transferring the service list to the computer system, the computer system being responsive to the service list to display a list of available services. Typically the method includes, in the input device: a) determining a service indication in accordance with a user input; and, 20 b) transferring the service indication to the computer system, the computer system being responsive to the service indication to: i) determine a gatekeeper; and, ii) enable communication between the gatekeeper and the input device. Typically the method includes, in the input device, communicating with the gatekeeper via a computer 25 system having a software agent installed thereon. Typically the method includes, in the input device: a) communicating with a computer system to determine if a software agent is installed; and, b) if no software agent is installed; i) accessing a software agent from a second store; and, 30 ii) transferring the software agent to the computer system.

WO 2008/086567 PCT/AU2008/000037 -4 Typically the method includes, in the input device: a) receiving the second information from the user; b) receiving a second key from the gatekeeper; c) encrypting the second information using the second key; and, 5 d) transferring the encrypted second information to the gatekeeper, the gatekeeper being responsive to: i) decrypt the encrypted second information; and, ii) compare the second information to predetermined second information to thereby perform the authentication. 10 Typically the method includes, in the input device: a) mutually authenticating the gatekeeper; and, b) transferring the second information in response to a successful mutual authentication. Typically the method includes, in the input device: a) accessing a fourth key from the first store; and, 15 b) performing the mutual authentication at least in part using the fourth key. Typically the method includes, in the input device: a) receiving connection data from the gatekeeper in response to a successful authentication; and, b) communicating with the service provider using the connection data. Typically the connection data includes a resource locator, and wherein the method includes, in the 20 input device, providing the resource locator to a computer system, the computer system using the resource locator to establish the connection with the service provider. Typically the method includes, in the input device: a) determining a second session key; and, b) communicating with the service provider at least in part using the second session key. 25 Typically the method includes, in the input device, communicating with the service provider via a gateway. Typically the method includes, in the input device: a) receiving user inputs; b) encrypting the user inputs; and, 30 c) transferring the encrypted inputs to a gateway, the gateway being responsive to decrypt the inputs and provide the inputs to the service provider.

WO 2008/086567 PCT/AU2008/000037 -5 Typically the method includes, in the input device: a) performing encryption using at least one encryptor; and, b) causing an indication of an encryptor status to be displayed using at least one of: i) an indicator provided on the input device; and, 5 ii) a computer system. Typically the method includes, in the input device, using an indicator for indicating at least one of: a) integrity and/or authenticity of an identity device; b) integrity and/or authenticity of the gatekeeper; c) integrity and/or authenticity of a gateway; 10 d) success or otherwise of authentication; and, e) success or otherwise of agent initialisation. Typically the method further includes having the user undergo authentication with the service provider. Typically the method is performed at least in part using an identity device owned by a user, to thereby 15 allow the user to establish a trust relationship with the gateway. Typically the method uses user centric security. Typically the user centric security facilitates the service provider's services in a manner suitable to the service provider's security model. Typically the method includes, having the user self validate using special hardware and software first 20 locally and then remotely. Typically the method assumes a computer system to which the input device is connected is untrusted. Typically the method uses a secure interaction device formed from a secure input device and a secure user identity device. Typically the method creates a secure connection between the interaction device and a gateway 25 mediated by a trusted third party device. Typically the method ensures provenance of the local hardware, local software, keys, and remote devices and their software to a user. Typically the method separates and updates encryption keys in a one-time manner.

WO 2008/086567 PCT/AU2008/000037 -6 Typically the first data includes encrypted provenance information, and wherein second data includes public provenance information. In a second broad form the present invention provides apparatus for performing a secure interaction, the apparatus including an input device for: 5 a) performing a checking operation using first information, to thereby confirm input device integrity; b) providing second information received from a user, to a gatekeeper, the gatekeeper being responsive to the second information to: i) perform authentication; and, 10 ii) establish communication between the input device and a service provider in response to a successful authentication; and, c) communicating with the service provider in accordance with user inputs to thereby perform the secure interaction. Typically the input device includes: 15' a) an input, for receiving inputs from a user; b) a connector for allowing connection to a computer system; and, c) an internal processing system for at least one of: i) controlling the operation of the input device; ii) interpreting inputs received via the input device; and, 20 iii) performing encryption; iv) communicating with at least one of: (1) a processing system; (2) an identity device; (3) a gateway; and, 25 (4) a gatekeeper. Typically the input device includes an indicator for indicating at least one of: a) integrity and/or authenticity of the identity device; b) integrity and/or authenticity of the gatekeeper; c) integrity and/or authenticity of the gateway; 30 d) success or otherwise of authentication; and, e) success or otherwise of agent initialisation. Typically the input device includes a connector for allowing connection to an identity device.

WO 2008/086567 PCT/AU2008/000037 -7 Typically the input device includes an encryptor for encrypting communication. Typically the input device performs the method of the first broad form of the invention. In a third broad form the present invention provides a method of performing a secure interaction, the method including, in an identity device, providing first data to an input device from a first store, the 5 input device being responsive to transfer the first data to an internal processing system, the internal processing system being responsive to use the first data to confirm input device integrity. Typically the method includes, in the identity device, providing second data to an input device from a second store, the input device being responsive to transfer the second data to the internal processing system, the internal processing system being responsive to use the first and second data to confirm 10 input device integrity. Typically the first data is stored as encrypted first data to thereby allow the first data to be decrypted at least in part using first information. Typically the first store stores an algorithm, the first information and the algorithm being used to determine a first key for decrypting the first data. 15 Typically the method includes, in the identity device, interacting with an input device to perform the method of the first broad form of the invention. Typically the method includes, in the identity device, using an indicator for indicating at least one of: a) integrity and/or authenticity of the input device; b) integrity and/or authenticity of a gatekeeper; 20 c) integrity and/or authenticity of a gateway; d) success or otherwise of authentication; and, e) success or otherwise of agent initialisation. In a fourth broad form the present invention provides apparatus for performing a secure interaction, the apparatus including a first store for storing first data, the first data being provided to an input 25 device, the input device being responsive to transfer the first data to an internal processing system, the internal processing system being responsive to use the first data to confirm input device integrity. Typically the identity device includes a second store for storing second data, the second data being provided to an input device, the input device being responsive to transfer the second data to the internal processing system, the internal processing system being responsive to use the first data to 30 confirm input device integrity.

WO 2008/086567 PCT/AU2008/000037 -8 Typically the second store stores at least one of: a) provenance information; and, b) a copy of an agent application. Typically the first store stores at least one of: 5 a) encrypted provenance information; b) encrypted first information; c) an encrypted sequence number; d) encrypted provenance information; e) an encrypted service list; 10 f) a first encryption key; and, g) a fourth encryption key. Typically the identity device includes a connector for connecting to the input device. Typically the apparatus includes an indicator for indicating at least one of: a) integrity and/or authenticity of the input device; 15 b) integrity and/or authenticity of a gatekeeper; c) integrity and/or authenticity of a gateway; d) success or otherwise of authentication; and, e) success or otherwise of agent initialisation. Typically the apparatus is for performing the method of any one of the third broad form of the 20 invention. In a fifth broad form the present invention provides a method of performing a secure interaction, the method including, in a gatekeeper: a) receiving second information from an input device; b) performing authentication using both the second information and user information; and, 25 c) establishing communication between the input device and a service provider in response to a successful authentication, the input device communicating with the service provider in agcordance with user inputs to thereby perform the secure interaction. Typically the method includes, in a gatekeeper: a) providing a second session key to the input device, the input device being responsive to 30 encrypt the second information using the second session key; b) receiving encrypted second information; WO 2008/086567 PCT/AU2008/000037 -9 c) decrypting the encrypted second information; and, d) comparing the second information to predetermined second information to thereby perform the authentication. Typically the method includes, in the gatekeeper: 5 a) mutually authenticating the input device; and, b) providing the second session key in response to a successful mutual authentication. Typically the method includes, in the gatekeeper, communicating with the input device via a computer system. Typically the method includes, in the gatekeeper, providing connection data to the input device in 10 response to a successful authentication, the connection data being used to establish a secure connection between the gateway and the input device. Typically the method includes, in the gatekeeper, receiving the connection data from a gateway. Typically the connection data includes a resource locator, and wherein the input device is responsive to the resource locator to provide the resource location to a computer system, the computer system 15 using the resource locator to establish communication with the gateway. Typically the method includes, in the gatekeeper: a) determining a service indication in accordance with a user input provided via the input device; and, b) determining a gateway using the service indication. 20 Typically the method includes, in the gatekeeper, performing authentication of an input device performing the method of the first broad form of the invention. In a sixth broad form the present invention provides apparatus for performing a secure interaction, the apparatus including a gatekeeper for: a) receiving second information from an input device; 25 b) receiving user information via an input device; c) performing authentication using the second information; and, d) establishing communication between the input device and a service provider in response to a successful authentication, the input device being responsive to communicate with the service provider in accordance with user inputs to thereby perform the secure interaction. 30 Typically the gatekeeper is a suitably programmed processing system.

WO 2008/086567 PCT/AU2008/000037 - 10 Typically the apparatus is for performing the method of the fifth broad form of the invention. In a seventh broad form the present invention provides a method for performing a secure interaction, the method including, in a gateway: a) in response to a successful authentication by a gatekeeper, generating connection data; 5 b) transferring the connection data to the gatekeeper, the gatekeeper being responsive to provide the connection data to an input device, thereby allowing a connection to be established between the input device and a service provider; and, c) transferring communication between the input device and the service provider. Typically the method includes, in the gateway: 10 a) generating the resource locator in accordance with a service selection, the service selection being indicative of a selected service provider; and, b) generating the connection data using the resource locator, thereby allowing an input device to establish a connection via a computer system with the selected service provider via the gateway. 15 Typically the resource locator has a limited life span. Typically the method includes, in the gateway: a) receiving a connection request from a computer system, the connection request being at least partially based on a resource locator; b) establishing a connection in response to the received connection request. 20 Typically the method includes, in the gateway: a) determining if the resource locator has expired; and, b) establishing the connection if the resource locator has not expired. Typically the method includes, in the gateway: a) receiving encrypted communication from the input device; 25 b) decrypting the encrypted communication; and, c) transferring the decrypted communication to the service provider. In an eighth broad form the present invention provides apparatus for performing a secure interaction, the apparatus including a gateway for: a) in response to a successful authentication by a gatekeeper, generating connection data; WO 2008/086567 PCT/AU2008/000037 - 11 b) transferring the connection data to the gatekeeper, the gatekeeper being responsive to provide the connection data to an input device, thereby allowing a connection to be established between the input device and a service provider; and, c) transferring communication between the input device and the service provider. 5 Typically the gatekeeper is a suitably programmed processing system. Typically the apparatus is for performing the method of the seventh broad form of the invention. In a ninth broad form the present invention provides a method of performing a secure interaction, the method including: a) performing a checking operation using first information provided via an input device, to 10 thereby confirm input device integrity; b) performing remote authentication of second information provided via the input device; c) establishing a connection with a service provider in response to a successful authentication; d) performing secure interaction with the service provider using the established connection. Typically the method includes: 15 a) connecting an identity device to the input device; and, b) performing the checking operating at least in part using first data stored on the identity device. Typically the method includes, performing the remote authentication in a gatekeeper, the gatekeeper being used to establish a connection between the input device and the service provider. Typically the method includes, establishing the connection via a gateway, the gateway and input 20 device being adapted to encrypt information transferred therebetween. Typically the method is performing using an input device performing the method of the first broad form of the invention. In a tenth broad form the present invention provides apparatus for performing a secure interaction, the apparatus including: 25 a) an input device; b) a processing system for performing a checking operation using first information provided via the input device, to thereby confirm input device integrity; c) a gatekeeper for: i) performing remote authentication of second information provided via the input device; 30 and, WO 2008/086567 PCT/AU2008/000037 -12 ii) establishing a connection with a service provider in response to a successful authentication, the connection being used to perform secure interaction with the service provider using inputs supplied via the input device. Typically the apparatus includes an identity device for storing first and second data, and where the 5 input device is responsive to connection to the identity device to thereby retrieve at least some of the first and second data. Typically the apparatus includes a gateway, the connection being established using the gateway. Typically the input device is for encrypting user inputs, and wherein the gateway is for: a) decrypting the user inputs; and, 10 b) providing the decrypted user inputs to the service provider. Typically the apparatus is for performing the method of the tenth broad form of the invention. In an eleventh broad form the present invention provides a method of performing a secure interaction, the method including: a) verifying operation of an input device at least in part using an identity device; 15 b) performing remote authentication at least in part using the identity device; and, c) establishing a connection with a service provider in response to a successful authentication. Typically the method includes: a) connecting the identity device to the input device; b) providing first information using the input device, the input device being responsive to the 20 first information to: i) retrieve first and second data from first and second stores in the identity device, at least in part using the first information; ii) providing the first and second data to a processing system, the processing system using the first and second data to verify the operation. 25 Typically the method includes, providing second information via the input device, the input device being responsive to provide the second information to a gateway, the gateway using the second information to perform the remote authentication. Typically the method includes establishing the connection via a gateway. Typically the method is performing using a input device for performing the method of the first broad 30 form of the invention.

WO 2008/086567 PCT/AU2008/000037 - 13 In a twelfth broad form the present invention provides apparatus for performing a secure interaction, the apparatus including: a) an input device; b) an identity device; 5 c) a processing system for verifying the operation of the input device using the identity device; and, d) a gateway for authentication the user, the gateway being responsive to a successful authentication to establish a connection with a service provider. Typically the apparatus is for performing the method of the eleventh broad form of the invention. 10 Brief Description of the Drawings An example of the present invention will now be described with reference to the accompanying drawings, in which: Figure 1 is a flow chart of a first example of an interaction process; Figure 2 is a schematic diagram of an example of a system for performing an interaction; 15 Figure 3 is a schematic diagram of an example of one of the servers of Figure 2; Figure 4A is a schematic diagram of an example of one of the computer systems of Figure 2; Figure 4B is a schematic diagram of a first example of an identity device; Figure 4C is a schematic diagram of a first example of an input device; Figures 5A and 5B are a flow chart of a second example of an interaction process; 20 Figure 6 is a flow chart of an example of a registration process; Figures 7A to 7H are a flow chart of a third example of an interaction process; Figures 8A and 8B are schematic diagrams of second and third examples of an identity device; Figures 9A and 9B are schematic diagrams of second and third examples of an input device; Figures 1 OA to I OC are schematic diagrams of examples of gatekeeper architectures; and, 25 Figures 11 A to 11 C are schematic diagrams of a specific example implementation. Detailed Description of the Preferred Embodiments An example of a process for performing interactions will now be described with reference to Figure 1. At step 100 an interaction device is registered for use. The interaction device is a device that is suitable for interacting with a terminal, such as a computer system, or other suitable communications 30 device, in order to control operation of the terminal. Accordingly, the interaction device may be in the form of a modified computer input device such as a keyboard or mouse. Alternatively the interaction WO 2008/086567 PCT/AU2008/000037 - 14 device could be formed from two separate physical devices such as a modified computer input device, and a separate identity device as will be described in more detail below. The registration process is typically performed by a trusted third party, which is at least partially responsible for operating the interaction process, as will be described below. The registration process 5 may be performed in any one of a number of ways but is typically performed to allow the interaction device to be populated with data required to perform the interactions, and to associate the interaction device with the user in some way. The registration process may also involve the creation of authentication information, such as a username and password, or the like. At step 110 when it is desired to perform an interaction, a checking operation is initially performed to 10 confirm the interaction device integrity. The checking operation may take on any one of a number of forms but typically involves having the interaction device access locked or encrypted data utilising information provided by the user, such as the authentication information. In such a case, failure to correctly access the data implies that the integrity of the interaction device is in some way compromised, in which case the interaction process typically fails. It will be appreciated however that 15, other checking operations may be performed. At step 120 remote authentication is performed utilising the interaction device. The remote authentication is typically performed by having the user supply authentication information via the interaction device, with this being transferred to an appropriate entity, for authentication. This allows the entity to compare the provided authentication information to that created during registration, to 20 thereby confirm both that the user is a registered user, and that the interaction device is a registered interaction device. In the event that the remote authentication fails, then the process typically ends. At this point the interaction device may be added to a list of excluded devices, preventing further interaction with the system, as will be described in more detail below. Otherwise, at step 130 a connection is established 25 with a service provider, such as a corporation, an ISP (Internet Service Provider) or the like, allowing interaction to be performed between the user and the service provider, using the interaction device, at step 140. The establishment of the connection is typically controlled by the authenticating entity, thereby allowing the user to be confident that the interaction is secure. This may be achieved in any one of a 30 number of manners, such as by having the authenticating entity provide a secure controller that creates a secure path between the interaction device and the application server via a secure server, as will be described in more detail below.

WO 2008/086567 PCT/AU2008/000037 - 15 It will be appreciated from the above that the process consists of a number of separate stages, which when performed aim to establish trust for the user in both the interaction device, and the service provider. In particular, the registration process enables the trusted third party to identify the interaction device 5 via the remote authentication process. Furthermore the use of the integrity check ensures that the interaction device is functioning correctly, and therefore has not been tampered with. Consequently, these checks in combination allow the trusted third party to confirm that the interaction device is a genuine interaction device intended for use with the system (and consequently is manufactured according to required specifications) and that the device is functioning correctly, and has not therefore 10 been compromised. In one example, this is referred to as establishing the provenance of the interaction device. In particular, the term provenance generally refers to the ability to establish the origin or source from which something comes, and the term is often used in the sense of place and time of manufacture, production or discovery. Accordingly, the above described process uses the registration, integrity 15 checks and authentication, to establish the provenance of the interaction device. This is achieved by having the interaction device prove its integrity to the user, through an appropriate verification, and then to a trusted third party using the remote authentication. This in turn allows the trusted third party to ensure that the interaction device satisfies any requirements for performing secure interactions, and to confirm that the interaction device has not 20 been tampered with. Thus, it will be appreciated that confirming the interaction device integrity, at the least allows the user to confirm that the device is functioning properly. This in turn allows the user to be confident that the device has not been tampered with in some way, which in turn helps confirm device security. Preferably however the integrity check also confirms to the user that the provenance of the interaction 25 device is satisfactory and hence that the interaction device is a genuine device registered to use the system and manufactured according to system operation requirements, which when combined with correct operation ensures device security. By virtue of a trust relationship established between the user and the trusted third party during registration, confirmation of the interaction device provenance by the trusted third party allows the 30 user to be confident of the security of the interaction device. Thus, the user is able to use their own trusted relationship with the trusted third party to trust the interaction device.

WO 2008/086567 PCT/AU2008/000037 - 16 Furthermore, as the trusted third party has established trust relationships with the service provider, this also allows the user to trust the service provider. Thus, following the above described process, the user can be confident when they access the service provider services, for example via a web-page, that they have not been redirected to a spoof web-site that simulates the services of the service provider. 5 This reduces the likelihood of the user being induced to provide security information, such as a username or password, to an entity that is passing themselves off as a genuine service provider, in order to gain the user's security information. In addition to this, the user can be confident that the interaction device they are using is secure, and this coupled with appropriate protocols, for example, which allow inputs provided via the interaction device to be encrypted, this allows the user to ensure 10 that interactions can be performed in a safe and secure manner. Accordingly, the above process allows the user to implement secure communication between the interaction device and the service provider, which in turn allows the user to utilise an untrusted computer system or the like to perform secure interactions in a trusted manner. In one example, the interaction device is formed from the concomitance between an input device and 15, an identity device. In this example, the identity device is associated with the user, and retained by the user at all times. The identity device includes secure data based on the user's authentication information. When the identity device is used with an appropriate input device, the input device performs a checking operation, as outlined above, by attempting to access the secure data stored in the identity device. In this instance, as the user can be assured of the security of the identity device; as 20 this physical device is their own responsibility, successful accessing of the secure data stored in the identity device allows the user to establish that operation of the input device is verified. It will be appreciated as part of this, that if the user at any stage loses physical control over the identity device, for example, if they lose the device, then they can no longer be certain of it's security. Accordingly, in this instance, the user would need to obtain another replacement identity device using 25 a suitable mechanism. This may therefore require that the user re-register, or alternatively, may require the user order a new device from the trusted third party administering the system. In any event, it will be appreciated that the user's ability to trust their own physical identity device can be used to enhance the level of trust in operation of the input device beyond that that would otherwise be obtained through the use of an internal check within an integrated interaction device alone. 30 It will be appreciated by a person skilled in the art that this process is typically implemented at least in part utilising a distributed computer architecture, an example of which will now be described with reference to Figure 2.

WO 2008/086567 PCT/AU2008/000037 - 17 In this example the system includes a number of servers 201, 202, 203, and a number of user computer systems 204, interconnected via communications networks 205, 206 as shown. In use, users interact with one of the computer systems 204 using the interaction device. The computer system 204 then communicates with the servers 201, 202, 203 via the communications 5 networks 205, 206 utilising appropriate communications protocols, such as TCP/IP, as will be appreciated by persons skilled in the art. The communications networks 205, 206 may be any form of wired or wireless communications networks, such as a Local Area Network (LAN), Wide Area Network (WAN), the Internet or the like. Thus, the communications networks 205, 206 may be any one or combination of public, private, 10 virtual, logical, internal or external networks. The servers 201 (hereinafter referred to as "gatekeepers") are adapted to perform the remote authentication and establish the connection between the servers 203 (hereinafter referred to as an "application server") and the computer systems 204, via a server 202 (hereinafter referred to as a "gateway"), as required. This allows the application servers 203, which are operated by service 15 providers, to provide interaction services, which may be any form of service, depending on the preferred implementation. It will be appreciated from this that the terms "gatekeeper" and "gateway" are for the purpose of explanation only, and is not intended to be limiting. Whilst the gateway and gatekeeper are shown as separate hardware devices, this is for the purpose of example only, and it will be appreciated that the gatekeeper 201 and the gateways 202 can be formed from physical or logically 20 separate or common devices. It will be appreciated from this that the servers 201, 202, 203 may be any form of physical or logical server and may be implemented using any suitable form of hardware or processing system. An example of a suitable configuration is shown in Figure 3. In this example the servers 201, 202, 203 include a processor 300, a memory 301, an input/output device (1/0) 302, an external interface 25 303 interconnected via a bus 304. In use the external interface 303 allows the servers 201, 202, 203 to be interconnected to the communications networks 205, 206 and/or any peripheral devices, such as the database 211, or another one of the servers 201, 202, 203. Although a single external interface 303 is shown, this is for the purpose of example only, and in practice multiple interfaces using various methods (eg. Ethernet, serial, USB, wireless or the like) may be provided.

WO 2008/086567 PCT/AU2008/000037 - 18 Accordingly, it will be appreciated that the servers 201, 202, 203 may be formed from any suitable processing system, such as a suitably programmed PC, Internet terminal, lap-top, hand-held PC, or the like, which is operating applications software to enable required functionality to be implemented. An example of one of the computer systems 204 is shown in Figure 4A. As shown in this example, 5 the computer system includes at least one processor 400, a memory 401, an output device 402, such as a display, and an external interface 403, interconnected via a bus 404 as shown. In this example the external interface 403 can be utilised for connecting the computer system 204 to the communications networks 205, 206, as well as to the interaction device, shown generally at 405. Again, although a single external interface 403 is shown, this is for the purpose of example only, and in practice multiple 10 interfaces using various methods (eg. Ethernet, serial, USB, wireless or the like) may be provided. In use, the processor 400 executes application software stored in the memory 401 to allow different processing operations to be performed, including, for example, communicating with the servers 201, 202, 203 via the external interface 403. Accordingly, it will be appreciated that the computer system 204 may be formed from any suitable processing system, such as a suitably programmed PC, Internet 15' terminal, lap-top, hand-held PC, smart phone, PDA, web server, or the like. In this example, the interaction device 405 is formed from an input device 410 and a concomitant identity device 420. The input device 410 includes embedded processing allowing the input device to communicate with memories provided on the identity device 420. Examples of the identity device 420 and input device 410 are shown in more detail in Figures 4B and 20 4C respectively. As shown in Figure 4B, the identity device 420 includes a PROM 421, a secret memory 422, a public memory 423 and a connector 424, for allowing connection to the input device 410. The PROM and the secret memory are connected via a one-way connection shown generically at 425. In one example, the identity device 420 also includes an indicator 426. The indicator is typically used to provide a 25 confidence indication, indicative of system and/or device integrity, which may be derived from system integrity checks that are performed. The indicator may provide an indication in any suitable form but generally generates a visual, audible or tactile indication. The indicator may therefore be of any suitable form such as a single multicolour LED, multiple LED's, small LCD, audible tone combination, vibration or any combination thereof. 30 It will be appreciated that the identity device 420 may be any suitable device, but in one example is formed from a USB style memory key with suitably configured memory. However, this is not WO 2008/086567 PCT/AU2008/000037 - 19 essential and any suitable device with embedded memory, such as a SIM (Subscriber Identity Module) card, smartcard, mobile phone (cell phone), or the like. Additionally, or alternatively, the identity device 420 could be formed from a device that includes embedded processing to allow encryption and authentication processes to be performed within the 5 identity device. Examples of this are shown in Figures 8A and 8B. It will be appreciated that in these examples, indicators may also be provided in a manner similar to that described above with respect to Figure 4B. As shown in Figure 4C, the input device 410 includes an input 411, such as a keypad or the like, a connector 412 to allow connection to the computer 204, and a connector 418, such as a USB 10 (Universal Serial Bus) connector, for connecting to the identity device 420. The input device 410 also includes some form of internal processing system, which in this example includes, a multi-purpose encryptor 413, a CPU 414, a memory 415, a PROM 416, and an input device controller 417. A one way gap is also provided between the PROM and memory as shown at 419. In one example, the input device 410 also includes an indicator 411 A, similar to the indicator 426 described above. 15 In use, input commands supplied via the input 411 are interpreted by the input device controller 417 and forwarded to the computer system 204 via the connection 412. In addition to this, the CPU 414 is adapted to execute instructions to perform the processes outlined above. For example, when the input device 410 and the identity device 420 are interconnected via the connections 418, 424, the CPU 414 communicates with the PROM 421, the secret memory 422 and the public memory 423 to access 20 information provided therein. The CPU 414 is also adapted to operate as a multi-purpose encryptor 413 to allow data to be encrypted prior to transfer to the computer 204. It will therefore be appreciated that the input device 410 can be formed from any suitable device, such as a custom computer keyboard including the required embedded processing and memory. However, alternatively other devices incorporating suitable memory and processing may be used, such as a 25 mobile phone, or the like. Alternative examples of the input devices are shown in Figures 9A and 9B. It will be appreciated that in these examples, indicators may also be provided in a manner similar to that described above with respect to Figure 4C. The input device 410 and the identity device 420 are suitably protected against physical intrusion and may also have electronic methods and other countermeasures incorporated to prevent their integrity 30 and the integrity of the data from being compromised.

WO 2008/086567 PCT/AU2008/000037 - 20 In any event, an example of the process performed by the identity device 420 and the input device 410, in the system of Figure 2, will now be described in more detail with reference to Figures 5A and 5B. At step 500 the identity device 420 is connected to the input device 410 that is already connected to the computer system 204. In this example, connection of identity device 420 to the input device 410 5 initiates the integrity and authentication check process, as will now be described. However, it will be appreciated that any suitable initiation method may be used. At this time, the identity device 420 can check the integrity of the input device 410 and provide an indication of the results using the indicator. This can be achieved in any suitable manner and could include, for example, having the input device 410 generate a checksum based on the content of the 10 PROM 416 and provide an indication of this to the identity device 420, allowing the identity device to validate the checksum and hence confirm the integrity of the input device 410. It will be appreciated however that any suitable check may be performed, such as requiring a predetermined response to a provide query or challenge. In response to the integrity check of the input device 410 the identity device 420 can cause an 15 appropriate confidence indicator to be displayed. This can involve for example, having the indicator 426 generate a positive or negative confidence indication. This may be achieved using any suitable technique depending on the nature of the indicator 426. Thus, for example, the indicator could be a red LED in the event that the integrity check fails, or green in the event that the integrity check succeeds. 20 Following this, the input device 410 can check the integrity of the identity device 420 in a similar manner, and provide an indication of the result of the check using the indicator 41 IA. In the above example, it will be noted that the result of the integrity check of the input device is displayed using the identity device and vice versa. Whilst this is not essential, it is preferable to ensure that a input device 410 or identity device 420 does not attempt to spoof a positive result in the 25 event that the integrity check fails. Thus, for example, if the input device 410 were to display the result of it's own integrity check, if the input device 410 has been compromised, then the input device 410 could be configured to display an indication that the integrity check of the input device 410 is successful, even if this is not the case. The input device 410 detects connection of the identity device 420, and causes the computer system 30 204 to prompt the user to enter first authentication information at step 505. This may be achieved in any one of a number of manners depending on the preferred implementation. Thus, for example, the WO 2008/086567 PCT/AU2008/000037 - 21 authentication information may be in the form of a password which can be entered via the hardware input 411. Alternatively this may be in the form of biometric information or the like which may require the provision of a suitable biometric reader within the input device 410. At step 510 the input device 410 and in particular the CPU 414 operates to unlock the secret memory 5 422 using first authentication information. This is typically achieved by having first data stored in the secret memory 422 encrypted using a suitable encryption algorithm, which is at least partially based on the authentication information. In this instance, the input device CPU 414 and/or the encryptor/decryptor 413 operates to generate a decryption key using the first authentication information, allowing the encrypted first data to be decrypted. It will be appreciated that this requires 10 appropriate configuration of the secret memory 422 and in particular the first data stored therein, when the identity device 420 is initially configured as will be described in more detail below. At step 515 a check is performed to ensure that the secret memory 422 is unlocked. This may be achieved in any one of a number of manners, but typically involves having the input device 410 compare decrypted first data retrieved from the secret memory 422, to second data retrieved from the 15 public memory 423. In this example, the first data can include an encrypted version of the second data, so that comparison of the decrypted first data and the second data allows the input device 410 to confirm the first data was successfully decrypted, and hence that the secret memory 422 was successfully unlocked. In one example, the first and second data can include at least the following information: 20 e first data - encrypted provenance information * second data - public provenance information If the secret memory 422 is not successfully unlocked, then the process typically ends. Furthermore, the input or identity devices 410, 420 may be excluded from further interaction using the system, as will be described in more detail below. 25 At step 520 the user is prompted by the computer system 204 for a service selection, which the computer system 204 uses to establish connection with the appropriate gatekeeper 201, at step 525. These steps are typically achieved by having the input device 410 obtain a list of available services from the first or second data, and forward this to the agent residing on the computer system 204. It will be appreciated that this list is typically created during the registration process as will be described 30 in more detail below. The list of available services includes an indication of a corresponding gatekeeper 201, so that when the user selects a service via the input device 410, this can be interpreted by the computer system 204 and used to establish a connection with the relevant gatekeeper 201.

WO 2008/086567 PCT/AU2008/000037 - 22 At step 530 the input and identity devices 410, 420 undergo mutual authentication with the gatekeeper 201. This may be achieved in any suitable manner, but typically involves exchanging authentication information, such as digital credentials, digital certificates or the like. The authentication information provided by the input device 410 may be obtained either from memory in the input device 410, or 5 from the identity device 420. The input device 410 collects the credentials from the identity device 420, with credentials from both the input and identity devices 410, 420 being sent to the gatekeeper by the identity device 410. As part of this process, an indication of a user identity (user ID) is collected by the input device 410 from the identity device 420, when the user enters their first authentication information. This 10 information is then "packaged", for example, by providing the first authentication information in an encrypted file together with any other information, ready for transmittal to the gatekeeper 201, once the aforementioned mutual authentication is completed. At this stage, the indicators 426, 41 IA can be used to display an indication of the integrity and/or authenticity of the gatekeeper. This may be achieved, for example by displaying an appropriate 15 indication depending on the results of the mutual authentication. At step 535 the user is prompted to enter second authentication information. Whilst this may be the same as the first authentication information, this is not typical and usually the user simply provides either another password or alternative biometric information, utilising an appropriate technique. At step 540 the gatekeeper 201 authenticates the second authentication information and this will 20 typically involves at least comparing the received second authentication information to predetermined second authentication information that has previously been stored in a store, such as a database, 211, during the registration process, as will be described in more detail below. A specific example of the authentication process is described in more detail below in Appendix D. If the authentication process fails, then the interaction process typically terminates, with either the 25 identity device 420, or the input device 410, optionally being excluded from further interaction. Otherwise, at step 545, following a successful authentication, the gatekeeper 201 establishes a connection between the input device 410 and a gateway 202 via computer system 204. This process will typically include arranging for the gatekeeper 201 to supply session keys to both the input device 410 and the gateway 202, allowing communications therebetween to be encrypted. 30 Again, at this time, the indicators 426, 41 ]A can be used to display an indication of the integrity and/or authenticity of the gateway, in a manner similar to that described above.

WO 2008/086567 PCT/AU2008/000037 -23 The gateway 202 provides onward connectivity to one of the applications servers 203, which is typically operated by a service provider, allowing the selected service or interaction to be performed. This is achieved by controlling client software implemented on the processing computer system 204, using the input device 410, allowing the application software running on computer system 204 to 5 communicate with the respective application server 203, via the gateway 202. In one example, when it is required to transfer data securely, such as if the user is providing authentication information to the applications server 203, the user can activate an encryption function. This causes the input device 410 to encrypt any information input by the user, using the session key supplied by the gatekeeper 201. This encrypted information is then forwarded by the applications 10 software, to the gateway 202 for decryption, before being transferred to the applications server 203. Accordingly, the above described interaction process involves using an integrity check and remote authentication process to allow a user to establish trust in an input device. In this instance, even though the user may not be able to "trust" the computer system 204, for example because this is a public terminal, or the like, the user is still able to perform interactions in a secure and trusted manner. 15 This is achievable because the user utilises their trust in their own identity device 420 to establish trust in the input device 410, using the integrity check and remote authentication. This trust is established by having the process confirm not only input device operation, but also the input device's provenance, which in turn confirms that input device is a genuine device intended for use with the system, and that the device has not been compromised. The user also uses their trust of the trusted third party to 20 confirm the applications server with which they are communicating is administered by a genuine service provider. This in turn that enables the user to perform secure interactions via the computer system 204. As part of the secure interaction process, any sensitive information transferred to the applications server 203 can be encrypted by the input device 410. As the untrusted computer system 204 is unable 25 to decrypt the information, this ensures security of the sensitive information even though it is being transferred via an untrusted computer system 204. It will be appreciated by a person skilled in the art that the above described process is for the purpose of example only and that a number of variations can be incorporated therein. It will be appreciated from the above, that whilst the explanation has focussed on users as individuals, 30 this is for the purpose of example only. In practice, user's can be any one or more individuals, organisations, companies, or physical or logical devices.

WO 2008/086567 PCT/AU2008/000037 - 24 Thus, for example, the user could be a security device, such as a security camera. In this instance, the user ID could be, for example, a serial number or the like, with the identity and input devices forming part of the security device. In this instance, when an individual is installing the camera, the individual could be required to activate the above described procedure, for example, by having the security 5 device provide authentication information from a secure internal store. In this instance, the security device therefore performs the function of both the input and identity devices, allowing the security device to register with the gatekeeper. By having the security device undergo both the integrity check and authentication, this ensures that the security device is operating correctly. Furthermore, this allows the gatekeeper to ensure that the 10 security device is a genuine security device, before initiating communication between the security device and a service provider, which in this example may be a monitoring service, allowing the security device to be monitored. This process can also be used to establish encrypted communication between the security device and the service provider, which in turn helps further enhance security. Specific Example 15 A specific example of the registration process will now be described in more detail with respect to Figure 6. In this example, at step 600 the user requests an input device and an identity device from an entity that operates the gatekeeper 201, and the gateway 202. The identity and input devices 420, 410 respectively, are generally manufactured as separate devices 20 using a separate process, and then populated with required data during the registration process. The manufacturing process typically involves creating the identity and input devices 420, 410 in accordance with predefined specifications to ensure that the identity and input devices 420, 410 are universally compatible with the computer system 204, and to ensure a required level of physical and logical security. To ensure the identity and input devices 420, 410 are from a genuine manufacturer 25 authorised to provide such devices, and that they are manufactured according to the required specifications, it is typical for provenance information to be stored on the identity and input devices 420, 410 during the manufacturing process. This provenance information will be described in more detail below. At step 605 the user provides authentication information to the trusted third party, typically by 30 contacting an authentication gatekeeper. For the purpose of interaction with the trusted third party, the user is identified solely through the use of the identity device 420. It is not necessary for the user's real identity to be known, and accordingly, the authentication information does not need to be linked WO 2008/086567 PCT/AU2008/000037 -25 to the user's proper identity, but rather could be based on a pseudonym, or the like. Thus, the authentication information is used to ensure that identity devices 420 in use are being used by their genuine owners, and not necessarily to actually identify the user. This allows the authentication information to be in the form of a password or the like, which would only be known to and which 5 would be unique to the user, but which does not necessarily have to be indicative of the user's identity. However, authentication information related to the user, such as biometric information can be used depending on the implementation. The authentication information may therefore be provided in any suitable manner, such as by the creation of a password, or by scanning relevant portions of the user's anatomy to generate appropriate 10 biometric information. Typically, the user has two different instances of authentication information, such as two different passwords, are used to allow independent authentication to be performed at different stages in the interaction process, as will be appreciated by persons skilled in the art. The user may require other instances of authentication information to proceed with the service, but the information known by the user in these cases is typically supplied and secured by the service provider. 15 At step 610 the user selects required services. This may be achieved in any one of a number of ways but typically involves having the user review an indication of service providers displayed on the computer system 204 currently allowing connection via the interaction process implemented by the gatekeepers 201 and gateways 202. Generally, there will be a unique gatekeeper 201 and unique gateway 202 for each required service, but not unique to the user. 20 At step 615 secret information is stored by the input device 410, in the secret memory 422 of an identity device 420, whilst public information is stored in the public memory 423, at step 620. The public and secret information may include any suitable information, but in general the secret information is at least partially based on the authentication information, whilst the public information includes at least some information used in performing the integrity checking operation. In general, the 25 information will include the provenance information, which can be used to check the identity device 420 satisfies manufacturing requirements and the like, and this is generally stored in the PROM 421, so that this cannot be subsequently modified. In one example, the memories of the identity device 420 include the following information: PROM421 30 e provenance information such as: * credentials * serial number WO 2008/086567 PCT/AU2008/000037 -26 * manufacturer * date of manufacture 0 manufacturing licence 0 bios revision 5 e other information secret memory 422 0 first authentication information 0 encrypted sequence number * encrypted provenance information 10 0 encrypted service list 0 encryption key for Z1 e encryption key for Z4 e next session encryption key for Z2 e identity device commissioning data 15 e other encryption information * other information public memory 423 * copy of agent " bios revision program for identity device 20 e bios revision program for input device * other information The nature of the stored information and the manner in which it is used, will now be described in more detail below. In one example, the user may only require an identity device 420, for example, if they are only to use 25 input devices 410 made available with public terminals. More typically however the user would require both an input device 410 and an identity device 420. In this example, at steps 625 and 630, provenance information and encryption keys are stored in the memories 415, 416. Whilst any suitable forms of information and encryption keys may be used, in one example, the memories of the input device 410 include the following information: 30 PROM416 * input device provenance information such as: * credential WO 2008/086567 PCT/AU2008/000037 - 27 " serial number * manufacturer * date of manufacture * manufacturing licence 5 * bios revision " other information Secret Memory 415 * session keys for ZI * input device commissioning data 10 At step 635, the identity device 420 and input device 410 are associated with the user with an indication of this being stored by the gatekeeper 201, for example in the database 211. The gatekeeper will also store any other required information, such as all or part of the secret information stored on the identity device, authentication information, or the like. Thus, this will typically require that the gatekeeper store at least the second authentication information and any other information required to 15 perform communications such as necessary encryption keys or the like. This information may also be distributed to any required gatekeepers as required. The user may use a different input device 410 to that issued during registration, for example if they use an input device in a public environment, such as an Internet Caf6. The association between the user and the input device 410 is therefore recorded at the gatekeeper for auditing purposes. Thus, for 20 example, if a user is excluded from using the system, any input devices 410 and identity devices 420 they have had commissioned/registered may be excluded. The geographic location of a device and the user may be used to stop fraudulent usage, for example by having GPS (Global Positioning System) information forming an integral part of any of the devices. In this instance, the input and identity devices 410, 420 can be registered for use in certain locations, 25 with use in other locations resulting in a failure during the integrity and authentication checking procedure. Additionally, following completion of the registration process, the user may decide they wish to use an existing identity device 420 with additional services, in which case the user can undergo a supplementary registration process. This can involve repeating any required stages of the registration 30 process using the existing identity device 420, such as having the identity device 420 updated with any information required to perform the additional services. Additionally, and/or alternatively, this can WO 2008/086567 PCT/AU2008/000037 -28 involve having the user contact an appropriate gatekeeper 201 using the interaction process, allowing the user to view and select available services. An example of the interactions sequence will now be described in more detail with reference to Figures 7A to 7H. For the purpose of this example, the features of the devices are as discussed in 5 further detail in Appendix A. At step 700, the user connects the input device 410 to an untrusted terminal 204 before connecting the identity device 420 to the input device 410 at step 710. At step 720, the input and identity devices 410, 420 perform self initiated mutual authentication. Mutual authentication requires that the identity device 420 include some form of embedded 10 processing, to allow the input device 410 to be authenticated. If such processing is not available, as in the case of the identity device 420 shown in Figure 4A, then step 720 typically involves one way authentication of the identity device 420 by the input device 410. Because the identity device 420 stores encrypted provenance and commissioning data, that can only be recognised by a properly commissioned input device 410, the mutual authentication is completed within the input device 410. 15 The authentication process will typically involve the exchange of the digital credentials or the like, as will be appreciated by persons skilled in the art, and this will not therefore be described in any further detail. However, it will be appreciated that this process will generally be performed without requiring any user intervention. At step 730 it is determined if this authentication is successful, and if not the process fails at step 740. 20 Whilst having the process fail may simply halt the process, additionally or alternatively, process failure may result in either one of the identity or input devices 420, 410 being excluded from further interaction with the system. Exclusion of devices is achieved by having the gatekeeper 201 add details of the input and/or identity devices 410, 420 to a list of excluded devices, stored for example in the database 211. As will be 25 described in more detail below, if an input or identity device 410, 420 is on the excluded list, it will not be possible for the respective device to be used within the system. If the authentication step fails, then an indication of this is provided to the gatekeeper 201, allowing the respective devices 410, 420 to be added to the exclusion list. Since communications with the gatekeeper 201 may not be possible, the indication may be stored in a latent store within the respective 30 device for delivery using an approved method at a later time.

WO 2008/086567 PCT/AU2008/000037 - 29 Either one or both of the input device 410 and identity device 420 can optionally indicate the success or otherwise of the authentication using the respective indicators 411 A, 426. Again the nature of the indication will depend on the preferred implementation, as described above. Assuming the authentication is successful at step 750 the input device 410 attempts to initialise an 5 agent installed on the computer system 204. The agent is a software application that provides certain functionality, such as interfacing with the computer systems TCP/IP stack, as will be described below and as set out in Appendix A in more detail. At step 760 if it is determined that an agent is not present on the computer system 204, the agent is downloaded from the public memory 423 by the input device 410, and installed on the computer 10 system 204 at step 770. However, in alternative examples, the loading of the agent may be achieved using any other suitable mechanism. Thus, for example, the agent may be loaded using an "untrusted" computer system port, by downloading the agent from a communications network such as the Internet, or by installing the agent from other physical media such as from a CD, or the like. Once an agent is installed at step 780 the agent is checked to determine if it is functioning correctly. 15 This is achieved by having the input device 410 provide a launch command to the agent to cause the agent to start. If it is determined that the agent is not functioning at step 790, for example if the agent does not respond to the launch command, then the process fails at step 800. Again, either one or both of the input device 410 and identity device 420 can optionally indicate the success or otherwise of the agent start up or initialisation process using the respective indicators 411 A, 20 426. If the agent is functioning correctly, the agent causes the computer system 204 to prompt the user for first authentication information at step 810. This will typically involve having the computer system 204 generate a dialogue box and display this to the user via the output device 402. At step 820 the user supplies first authentication information to the input device 410 utilising an appropriate 25 technique. This may include therefore entering a password via the keyboard 411 or alternatively presenting a portion of their anatomy to a suitable biometric reader, to thereby allow biometric authentication information to be determined. At step 830 the input device downloads a software key and optionally an encrypted executable file, from the public memory 423 of the identity device 420. The input device 410 then uses the key and 30 executable file, as well as the first authentication information to generate a secret memory access method at 840. The executable file typically represents a unique algorithm that is used in generating WO 2008/086567 PCT/AU2008/000037 - 30 the secret memory key, and this will typically be unique to each identity device 420. Using the executable file from the identity device 410 means that the secret memory key can only be generated with the identity device 420 present and correctly operational, thereby further enhancing security. The executable file would ideally be replaced with a new executable file delivered from the gatekeeper 201 5 to the identity device 420 via the input device 410 after each service session initiation. The executable delivered from the gatekeeper 201 to the identity device 420 would typically be unique and would be encrypted using the input device 410, the user's first authentication information and the key, The input device 410 would contain a method for performing this action. The method would be transportable, and if the identity device 420 was used with another input device 410 at its next use, the new input 10 device 410 would be capable of accommodating the new files and the user's first authentication information to unlock the identity devices 420 secret memory. There is a separate unique executable file for each service listed in the identity device 420. The secret memory key is used by an encryptor Z1, which may be a dedicated encryption module, as shown for example in Figure 1 I B, or may be implemented by the multipurpose encryptor 413 shown 15 in Figure 4C. Accordingly, it will be appreciated that the key downloaded from the secret memory 422 is the Z1 key mentioned above. At step 850 the input device 410 uses the secret memory key to unlock the secret memory 422 in the identity device 420. This is generally achieved by having the input device 410 access at least some of the encrypted information stored in the secret memory 422, and then decrypt this using the encryptor 20 Z1. At step 860 it is determined if the unlock process is successful, which may be achieved in any one of a number of ways, but typically involves having the input device 410 determine if the encrypted information can be successfully decrypted. Thus, this process provides an integrity check to ensure the input and identity devices 410, 420 are 25 functioning correctly. This typically involves performing a calculation based on information extracted from the secret memory 422, and then examining the result to determine if this is as expected. Thus, for example, this can include calculating a checksum or hash value based on information that has been retrieved and decrypted from the secret memory 422 and comparing this to an indication of the checksum or hash value stored in the public memory 423 to confirm these agree. In the event that 30 there is a discrepancy, this indicates that the input device 410 was unable to correctly unlock the secret memory 422, which in turn indicates that the integrity check has failed.

WO 2008/086567 PCT/AU2008/000037 -31 If the unlock process is deemed to be unsuccessful, the process fails at step 870. In particular, this indicates that the either input device 410 or the identity device 420 are not functioning as expected and hence that the input device 410 or identity device 420 cannot be trusted. For example, this may be due to the fact that the input device 410 is not an authentic input device 410, that the input device 410 is 5 not registered for use with the system, or that the input device 410 has been tampered with in such a way as to affect it's operation. Otherwise, if the unlock is successful, and the integrity of the input and identity devices 410, 420 is confirmed, then at step 880, the input device 410 extracts some of the information from the secret memory 423, and typically extracts at least credentials, the provenance information and the service 10 list. The process then moves onto step 890, with the input device 410 providing the decrypted service list to the agent, to allow the agent to determine available services at step 900. In particular, it will be appreciated by persons skilled in the art that the service list corresponds to the services for which the user is therefore registered. This can include any services selected during the initial registration procedure, or any additional services selected via interaction with an appropriate gatekeeper 201 as 15 described above. At step 910 the agent causes the computer system 204 to display a list of available services, for example using a suitable user interface, such as a dialogue box or the like. At step 920 the user selects a desired service using the input device 410, which in turn transfers an indication of the selection to the agent. It will be appreciated that in fact this may involve having the agent receive signals 20 indicative of user input commands, which are then suitably interpreted to determine the service selection. At step 930, the agent uses the selection to identify an appropriate gatekeeper 201 from the service list. The agent then initiates communication with this gatekeeper at step 940, allowing the gatekeeper 201 and input device 410 to exchange credentials and perform mutual authentication at step 950. 25 The mutual authentication process may involve having the gatekeeper 201 examine a sequence number obtained from the secret memory of the identity device 420. The sequence number is updated by the gatekeeper 201 each time the identity device 420 is used. Accordingly, comparing the received sequence number to a sequence number stored at the gatekeeper 201 when the identity device 420 was last updated, allows the gatekeeper 201 to confirm the input device 420 has not been duplicated and 30 fraudulently used. In particular, if the identity device 420 is duplicated, and the duplicate device used, the sequence number on the duplicate device will be updated and consequently, the sequence number in the original device is now out of sequence, allowing this to be determined the next time the original identity device 420 is used.

WO 2008/086567 PCT/AU2008/000037 -32 At this stage, the gatekeeper 201 needs to know whom or what the user is, based on the user ID. Accordingly, the user ID is collected by the input device 410 from the identity device 420, when the user enters their first authentication information. The user ID is then "packaged" before being transferred to the gatekeeper 201. This ensures that gatekeeper 201 knows who is trying to 5 communicate and accordingly, what or other authentication information to expect. During this process the information transferred between the input device 410 and the gatekeeper 201 is typically encrypted utilising an encryptor Z4. To achieve this, the initiation of communication with the gatekeeper 201 involves the exchange of public keys for use in the encryption. Thus, for example, the encryptor Z4 will receive a public key of the gatekeeper 201, allowing this to be used to encrypt 10 information transferred from the input device 410 to the gatekeeper 201. Similarly, information received from the gatekeeper 201 is encrypted using a suitable public key so that the information can be decrypted by the encryptor Z4 using a key obtained from the secret memory of the identity device 420. Thus, this allows the credentials to be encrypted utilising the Z4 encryption key and transferred to the gatekeeper 201 for authentication with a reciprocal process also being performed. 15 At step 960 it is determined if the check has been successful and if not the process fails at step 970. Otherwise at step 980 the input device 410 indicates to the agent to expect a session key for encryptor Z2. At step 990 the gatekeeper 201 generates a session key, before transferring this to the input device 410 via the agent at step 1000. Either one or both of the input device 410 and identity device 420 can optionally indicate the success 20 or otherwise of the authentication using the respective indicators 411 A, 426. At step 1010 the agent causes the computer system 204 to prompt the user for second authentication information which the user then supplies via the input device 410 at step 1020. Again, it will be appreciated that the manner in which this is achieved will depend on the nature of the second authentication information, as previously discussed. 25 At step 1030 the input device 410 encrypts the second authentication information using the encryptor Z2 and associated session key. The encrypted second authentication information is sent to the agent at step 1040, which in turn forwards the encrypted second authentication information to the gatekeeper 201 at step 1050. At step 1060 the gatekeeper 201 decrypts the authentication information sent from the input device 30 410 using the session key generated at step 990, before using the second authentication information to attempt to perform the remote authentication process at step 1070.

WO 2008/086567 PCT/AU2008/000037 - 33 It will be appreciated that the authentication step this typically involves having the gatekeeper 201 compare the received second authentication information to second authentication information stored in the database 211 during the registration process. Accordingly, this operates not only to check that the user is authentic, but also that both the identity device 420 and the input device 410 are functioning as 5 expected, otherwise the second authentication information received from the input device 410 would be incorrect. In the event that the received and stored second authentication information do not match, then at step 1080 it is determined that the authentication has failed and the process fails at step 1090. Otherwise, at step 1100 the gatekeeper 201 generates secret session information, and forwards this to both the 10 input device 410 and to a gateway 202. In this regard, the gateway 202 used will depend on the service selected by the user, and hence the applications server 203 to which connection is ultimately required. At step 1120 the input device 410 configures an encryptor Z3 utilising a key contained in the secret session information, obtained from the gatekeeper 201. At step 1130, the gateway 202 uses the same 15 key to allow an equivalent physical or logical encryption process to be provided that complements the key sent to the input device 410 encryptor Z3. At step 1140 the gatekeeper 201 seeks a unique session token from the gateway 202, which in response to this generates the session token and forwards to the gatekeeper 201 at step 1150. At step 1160, the gatekeeper 201 then forwards the session token to the input device 410 via computer system 204, with the input device 410 operating to detect a session 20 preamble in the session token at step 1170. At step 1180, the input device 410 indicates to the agent that the encryption status is "on", with this being used by the agent to cause the computer system 204 to display an input device 410 encryption "on" status indication at step 1190. Alternatively however the input device 410 may be provided with an indicator such as an LED or the like, which is activated when the encryption status is on 25 At step 1200, having received and decrypted the session token, the input device 410 forwards the session token to the agent. The session token may be in any one of a number of forms but may in one example include information that is used to allow communications to be implemented between the computer system 204 and the respective gateway 202. In one example this may be in the form of a URL including an IP address or the like for the gateway 202, but can include any suitable information, 30 such as a script or the like, which can be used by the computer system 204 to allow the connection to be established. In any event, the returned session token must be honoured by the gateway 202 as a valid, expected access instrument, from a validated device. The session token will have a recognisable time dependency set by the gateway 202, and will not be valid outside this period.

WO 2008/086567 PCT/AU2008/000037 - 34 At step 1210 the agent launches an application provided on the computer system 204 to allow interaction with the application server 203. In one example, this is Internet web browser, or the like, which is launched using the information provided in the session token, allowing the application to initiate contact with the gateway 202. At step 1220 the application communicates with the gateway 5 202, allowing the gateway 202 to forward the communication to the application server 203 to allow interaction to proceed at step 1230. Thus, in this example, the URL is loaded into the Internet browser allowing the browser to access a web page hosted by the application server 203, with this communication being made via the gateway 202. 10 As will be appreciated by persons skilled in the art, subsequent communications between the input device 410 and the applications server 203 can utilise encryption, using the encryptor Z3. In this example, when the input device 410 is being used to control the applications software provided on the computer system 204, then the encryptor Z3 is typically turned off, allowing the input commands supplied by via the input device 410 to be interpreted by the applications software. 15 Similarly, if information transferred between the input device 410 and the applications server 203 is not sensitive and does not need to be encrypted, then again the encryptor Z3 can remain turned off. However, if sensitive information is to be supplied to the applications server 203, such as third authentication information, which may be required in order for the applications server 203 to provide access to services, then the encryptor Z3 can be activated. In this instance, inputs made using the 20 input device 410 are encrypted using the encryptor Z3 and transferred to the gateway 202. The gateway 202 decrypts the inputs and transfers these to the application server 203. Where the application, for example in the form of a web based application, requires industry standard encryption to function with the server application, the computer system 204 may be responsible for encrypting that data and Z3 may be turned off. 25 Thus, for example, if the user is performing Internet banking, so that the applications server 203 is operated by the user's bank, then this allows the user to logon to the system using a public untrusted terminal, using the input and identity devices 410, 420. In this instance, the input device 410 may form part of the public terminal. In this case, the software agent may be an adjunct to the computer system 204 application, recognised by that computer system 204 application, and expecting control 30 information to pass to and from both the input device 410 and the computer system 204 application.

WO 2008/086567 PCT/AU2008/000037 - 35 During the above described process, it may be necessary to provide information to the identity device 420. This can include, for example, updating either the sequence number or executable file, stored in the identity device 420. Failure to update the sequence number or executable file can result in incorrect operation of the identity device 420 the next time the system is used, which can lead to the 5 identity device 420 failing either of the integrity check or the authentication. Accordingly, the identity device 420 may need to remain coupled to the input device 410, at least until the sequence number and executable file are updated, which typically occurs at around the time when the gatekeeper provides the session information at step 1100. To ensure this requirement is meant, the input device 410 can include a lock that physically locks the identity device 420 into the connection 10 418, thereby ensuring the identity device 420 cannot be removed until the updating is completed as required. By performing the above described integrity check and the remote authentication, this allows the user to establish trust in the input device 410. The user can then launch a browser application on the public terminal and access a web page hosted by the applications server 203. When the user is to access their 15 Internet banking, they are typically required to provide a username and password, which are known only to the bank and the user. Accordingly, in this instance, it is important to ensure that the terminal is unable to intercept or at least interpret this information. For example, as the terminal is untrusted, it may include software that records communications, allowing information such as input usernames and passwords to be subsequently viewed by a third party. 20 However, in this example, when the user is asked to enter their password, the user can turn on the encryptor Z3, in which case the password is encrypted before it is transferred from the input device 410, to the gateway 202. Accordingly, any recording software on the terminal would be unable to decrypt the password, thereby rendering it useless to third parties. The terminal would echo to the screen an indication of a keystroke - but not the keystroke itself. 25 Accordingly, by establishing trust in the input device 410, using the identity device 420, this allows the user to perform secure interactions without the risk of confidential information being intercepted and fraudulently used by third parties. Thus, the above described processes utilise the replacement of untrusted input devices with verifiable trusted devices, such as the input device 410 and the identity device 420, which can then be used in an 30 architecture similar to that shown in Figure 2. The process empowers the user to establish a trust relationship between their identity device 420 and the input device 410 using authentication such as a passphrase or the like.

WO 2008/086567 PCT/AU2008/000037 - 36 The trusted input device then establishes a trust relationship with the gatekeeper 201 via the agent. As the gatekeeper 201 always has a trust relationship with the gateway 202, by virtue of them being implemented and controlled by the same entity, this allows the gatekeeper 201 to establish a trust relationship between the trusted input device 410 and the gateway 202, which again can be invoked 5 following provision of suitable authentication information. Following this, as the applications server 203 typically has a trust relationship with the gateway 202, this allows the user to maintain their relationship with the service provider in a manner determined by the service provider. The establishment of trust is performed on the basis of provenance by ensuring that the input device 10 410, the identity device 420 and the agent are manufactured in such a manner as to allow the user (provenance user) to establish and be satisfied of their provenance. In one example, software can be provided that can be used to establish provenance checks & produce reports. It will be appreciated that the above described process can provide a number of different principles compared to existing secure interaction techniques. 15 For example, the process operates by using a number of different data checks to ensure security is maintained. In particular, this is performed to empower the user to the trust the interaction device used in performing the interaction. This empowerment can be achieved by checking the provenance of the interaction device, and by using the data checks to ensure correct operation. In the event that the provenance and operation are 20 confirmed, this allows the user to trust that the interaction device has not been tampered with, or otherwise compromised, and that it meets requirements for secure interaction. Furthermore, by establishing the trust via an independent trusted third party, this allows the user to trust a connection established between the input device and a gateway. This obviates the need to trust the terminal to which the input device is connected, or the applications software installed thereon. 25 Furthermore, the system can be used to prevent unwanted interactions occurring, and can be used to exclude interaction devices that have been compromised, further enhancing the provided security. The process uses a separation of powers between different devices, so that the user can be provided with a portable identity device 420 that can be used in establishing trust in any input device 410. The input device 410 can then be used to allow the user to be authenticated by the gatekeeper 201, thereby 30 separating powers between the input and identity devices 410, 420, so that both devices are required to perform an interaction.

WO 2008/086567 PCT/AU2008/000037 - 37 The process can provide an identity balance, so that trust is established by users providing user centric security. This involves the user self verifying the input device 410 using the identity device 420. In the event that the user looses an identity device 420, the lost device can simply be excluded from further interaction, and a new identity device 420 provided, thereby maintaining the user's trust. 5 Additionally, by requiring service providers to use the process, this allows the user to ensure that trust is established between the service provider and the authenticating entity or gatekeeper 201. As a result, the user can absolutely trust that the connection is established with a genuine trusted service provider and not a spoof service provider. The above described process is not generally used to establish the user's identity to the service 10 provider, and this is typically achieved using existing authentication techniques, such as through the use of usernames and passwords or biometric information. This is performed via the gateway 202, so sensitive information transferred from the input device 410 to the service provider can be encrypted, thereby maintaining secrecy of the passwords, biometric information or the like. In the above described examples, the trust is established via the gatekeeper 201, which is in turn 15 implemented by the trusted third party. The gatekeeper 201 operates to establish the required trust and then establish a connection between the input device 410 and the gateway 202. Once this is complete, no further intervention by the gatekeeper 201 is required. The use of an agent installed on the terminal to which the input device 410 is connected, allows operation of the agent to be verified by the input device 410 without requiring that applications 20 software provided thereon is secure. The agent also allows routing of data between the input device 410, gatekeeper 201 and gateway 202. The system uses a provenance hierarchy to establish trust between the entities, with the trust being established via the gatekeeper 201. The above described process also uses a combination of hardware and software processes, so that the 25 user can be confident that if their hardware interacts correctly, the interaction will be secure. This avoids issues associated with trust established solely by software processes which can be circumvented by spoofing using software that mimics and/or records the operation of the software process. Examples of additional features that may be implemented as part of the above described process 30 include: WO 2008/086567 PCT/AU2008/000037 - 38 " one off pad password encryption * fec encrypt " RFID (Radio Frequency Identification) memory isolation * various interaction device implementations such as: 5 e phone * dongle e usb keyboard * computer in keyboard with ethernet * virtual keyboard 10 e dongle + memory * dongle with display * ttp (Trusted Third Party) video (streaming in and out) * ttp sense of presence "follow me" * ttp VoIP (Voice Over IP) encryption 15 * ttp spam repudiation The term user is intended to cover any one or more individuals, organisations, groups, companies, or the like. In addition to this, however, users can be formed from appropriately configured systems, such as hardware devices. This can be used, for example, in validating a device for use within a system. 20 Persons skilled in the art will appreciate that numerous variations and modifications will become apparent. All such variations and modifications which become apparent to persons skilled in the art, should be considered to fall within the spirit and scope that the invention broadly appearing before described.

WO 2008/086567 PCT/AU2008/000037 - 39 Appendix A Examples of features of specific examples of devices used in the processes above will now be described in more detail. Software Agent 5 This is an application that resides on the computer system 420 and which operates to relay communications between the input device 410 and the gatekeeper 201 and gateway 202. The software agent only ever operates based on instructions received from the input device 410. Gatekeeper 201 The gatekeepers 201 operate to perform the remote authentication, and therefore stores any data 10 required to perform this in the database 211. The remote authentication may include authenticating any one or more of the following: * the input device 410 * the identity device 420 " session numbers unique for each interaction 15 * the second authentication information as supplied by the user The gatekeepers 201 may also operate to check the provenance of the input and/or identity devices 410, 420, as well as to check the sequence and session numbers. Example operation of the gatekeeper is described in more detail in Appendix B. Gateway 202 20 Gateways 202 operate to provide onward connectivity to applications servers 203. The gateways 202 authenticate to gatekeepers 201, and operate to transfer application opening information to the software agent. The opening information is unique to each user session, so that each time a session is launched, the opening information is updated. Consequently, when a new session is to be commenced, the opening 25 information can be compared to the updated opening information supplied during the previous session. This helps to provide an additional level of security. Connectivity via the gateways 202 can only be activated in response to an encrypted request for user access from a known, trusted gatekeeper 201.

WO 2008/086567 PCT/AU2008/000037 - 40 The gateway 202 also acts to allow encrypted communications with the input device 410 using session encryption keys received from the gatekeeper 201. Example operation of the gatekeeper 201 is described in more detail in Appendix C. Input Device 410 5 The input device 410 is used to allow the user to provide input commands to the computer system 204, as well as to provide information to the gatekeepers 201 or gateways 202, via the computer system 204. Some of the features of the input device 410 are listed below: * registered by the manufacturer at manufacture 10 e built to predetermined standards e physically secure * has a unique serial number * has one or more microprocessors e has data memory 15 0 may have one or more public and private encryption key sets * is capable of running one or more encryption processes concurrently * can operate in either unencrypted or encrypted modes * may be, but is not limited to a computer keyboard * requires a provenance identity device 420 to operate in encrypted mode 20 e may be paired at manufacture with a provenance identity device 420 * may be connected to a device 204 with an untrusted operating system using any appropriate physical or wireless medium. This includes, but is not limited to usb, ethernet, 802.11, smartcard, bluetooth and any other proprietary method. * may be connected to a device 204 with an untrusted operating system using any 25 appropriate communications method. This includes, but is not limited to usb methods, wireless methods * may have one or more external ports for the connection of provenance identity devices 410 * may have an internal provenance identity device 410 30 e may use the untrusted operating systems 204 communication interfaces. * only creates a trust relationship with the provenance gatekeeper 201 and provenance gateway 202 after the trust and validation have been established.

WO 2008/086567 PCT/AU2008/000037 - 41 * may have one or more physical keys, displays or indicators associated with the engagement process e upgrades to bios and other internal requirements via second port The input device 410 may be controlled by a user and includes, but not limited to digital or analogue, 5 keyboards, handsets, headsets, sensors, readers, scanners, signature pads, smart pens, biometric methods and mobile communications devices (e.g. cell phones, wireless devices). Provenance Identity * a provenance identity identifies a provenance user. * a provenance user may have more than one provenance identity 10 e a provenance identity may be associated with a trusted hierarchy Identity Device 420 The identity device 420 is used to maintain the user's provenance identity, and is used to allow the integrity of the input device 410 to be checked. Features of the identity device include: * registered by the manufacturer at manufacture 15 0 built to provenance standards * physically secure * has a unique serial number * may be a master in a provenance identity hierarchy * may have one or more microprocessors 20 e has data memory partitioned into secure and insure areas 0 insecure memory has both read-write and read-only memory 0 may have one or more public and private encryption key sets * may be capable of running one or more encryption processes concurrently * may transfer data in either unencrypted or encrypted modes 25 e may be, but is not limited to a usb flash or cellphone device. * requires a trusted input device 410 to operate in encrypted mode * may be paired at manufacture with a trusted input device * may be connected to a device 204 with an untrusted operating system using any appropriate physical or wireless medium. this includes, but is not limited to usb, ethernet, 30 802.11, bluetooth and any other proprietary method for the purpose of upgrades when not in session or insecure read-write memory use during session WO 2008/086567 PCT/AU2008/000037 - 42 * may be connected to a device 204 with an untrusted operating system using any appropriate communications method. this includes, but is not limited to usb and ethernet methods or wireless methods * may use the untrusted operating systems 204 communication interfaces. 5 e only creates a trust relationship with the provenance gatekeeper 201 and provenance gateway 202 after the trust and validation have been established. * may have one or more physical keys, displays or indicators associated with the engagement process Accordingly, the identity device 420 can be any secure device that contains information pertinent to 10 the users requirements, including, but not limited to: encryption keys, application server permissions, biometric information and personal information. The identity device 420 normally requires an input device 410 to allow communications with a gatekeeper 201. In the case of an identity device 420 being a cellphone, the identity device 420 is typically constructed in such a manner as to allow proper security protocols between the gatekeeper 15 201 or gateway 202. In this case the identity device 420 only communicates with a gateway 202 after being given permission through the gatekeeper 201. An example hardware implementation of system utilising currently available hardware is shown in Figures I1A to IIC. In this example, the identity device 420 and input device 410 are formed from respective computer 20 systems implementing executable code to provide the functionality outlined above with respect to Figures 4B and 4C, such as required encryption and control. Required passcodes can be provided on removable media such as USB keys or the like. The computer systems can be connected via a suitable connection, such as an Ethernet connection, or the like. The input device 410 can then be coupled to an untrusted computer system 204 (not shown), via an Ethernet connection, or the like. 25 As shown in Figure 11 B, the gatekeeper 201 can also be formed from a suitably programmed computer system. The gatekeeper is coupled to a provenance database via a private network, such as a LAN or the like, via connections 14. In addition to this, the gatekeeper and database can be coupled to the untrusted computer system 204 via a network connection 12, such as via an Ethernet network. The gatekeeper is also coupled to a gateway 202 via an Ethernet connection 13. In the example of 30 Figure 11 C, the gateway 202 is also formed from a suitably programmed computer system, which is in WO 2008/086567 PCT/AU2008/000037 - 43 turn coupled to a merchant application implemented on a further computer system 203, via an Ethernet connection. It will be appreciated that the example shown in Figures 1 IA to I IC allows the techniques described above to be demonstrated and highlights the division of process that is utilised. However, in practice, 5 the system would be implemented as described above, using custom hardware, to thereby reduce hardware requirements.

WO 2008/086567 PCT/AU2008/000037 - 44 Appendix B Operation of the gatekeeper 201 will now be described in more detail. In particular, the gatekeeper 201 is a device that manages the connection between the remote terminal 204 and the gateway 202. The gatekeeper 201 is a secure device, with all data files on the device encrypted and secured. 5 The gatekeeper 201 is typically a computer server or cluster of computer servers that facilitate the purposeful allowance of communications between remote users and a secure gateway 202 or cluster of secure gateway 202s. A single gatekeeper 201 may consist of one or more of the following combinations: a single CPU, multiple CPUs, multiple motherboards with single CPUs, and multiple motherboards with multiple 10 CPUs. The gatekeeper 201 model is scalable both in the following terms: * Security o Physical o Logical 15 o Lower security models will be cheaper o Enterprise models * Power * Hardware based * Virtual Machine based 20 The gatekeeper 201 can consist of a single operating system or a host operating system with multiple virtual guest operating systems. Physical security is typically maintained by combining physical mechanisms and logical processes. The gatekeeper 201 typically has four or more communications ports used for the following purposes: * External port through which communications to the remote user systems are directed. The 25 number of external ports in place is dependent upon the system requirements. * A gateway 202 port through which secure communications with the gateway 202 are directed and maintained. Although multiple gateway 202s in the same gateway 202 cluster may be contacted, there is only ever one gateway 202 port. This suggests the use of a load balancing mechanism.

WO 2008/086567 PCT/AU2008/000037 - 45 * Provenance port through which the gatekeeper 201 receives software updates, maintains audit processes and maintains communications in order to allow registration checks to take place. " Management port through which secure communications allow high level management functions. 5 e When required, a gatekeeper 201 will have a port or ports dedicated to maintaining communications with other gatekeeper 201 cluster members. The gatekeeper 201 may also be maintained from an industry standard console consisting of an external keyboard, pointing device and a monitor. An example of a single motherboard model gatekeeper 201 is shown in Figure 1 OA. 10 In this example, the gatekeeper 201 includes a network 1/0 1000, coupled to a monitor 1001, a keyboard 1002 and a pointer device 1003, such as a mouse. The network 1/0 is coupled via a bus 1004 to a computer controller 1005. In this example, five network encryptors 1010, 1011, 1012, 1013, 1014 are also provided for encrypting communications via the communications ports described above, thereby allowing encrypted communication with remote users, application gateways 202, the 15 provenance network and management, via one or more physical, logical or virtual networks. The single motherboard model gatekeeper 201 typically uses either hardware or software encryption onto the data bus 1004. The network encryptors 1010, 1011, 1012, 1013, 1014 are controlled by the control computer 1005, allowing encryption to be performed using a different key on each port. The network encryptors 1010, 1011, 1012, 1013, 1014 may be separate computer systems in their own 20 right or a dedicated encryptor engine (hardware or software), controlled by the control computer 1005. The gatekeeper 201 is normally an exclusive device that will only pair with one gateway system 202. However, in some circumstances, the gatekeeper 201 may associate with more than one gateway 202 system. An example of a multiple motherboard gatekeeper 201 is shown in Figure 1OB. 25 In this example, the gatekeeper 201 includes multiple motherboards that are mounted in the same chassis providing physical isolation between gatekeeper 201 processes. In this example, the system includes a control board 1020, and four encryptor motherboards 1021, 1022, 1023, 1024. In use, each motherboard operates a separate process, with the control board 1020 providing connectivity to the monitor 1001, keyboard 1002 and pointer device 1003. The control board 1020 uses a KVM or the 30 like to allow local console access to each motherboard.

WO 2008/086567 PCT/AU2008/000037 - 46 An example of a virtual motherboard model gatekeeper 201 is shown in Figure 1 OC. In this example, the gatekeeper 201 includes a host server 1030 capable of implementing a number of virtual machines, with four shown at 1031, 1032, 1033, 1034 in this example. In this example, the virtual machines 1031, 1032, 1033, 1034 are generated by an application running on the host server 5 1030. Their configuration is derived from encrypted files stored on the host server 1030, with the host server 1030 only being accessible from the console. The gatekeeper 201 typically maintains software processes such as: * Communications processes with multiple remote user systems 0 Communications processes with other gatekeeper 201s in the cluster 10 e Communications processes with gateway 202s * Communications processes with manufacturers databases * Communication processes with auditing systems * Communications processes with licensing systems , Communications systems with management systems 15 * Communications systems with console systems * Security systems for encrypting communications e Security systems for encrypting databases * Security systems for ensuring device physical integrity * Security systems for ensuring operating systems integrity 20 e Database systems for registrants * Database systems for system integrity * Encryption tables 0 Audit systems 0 Cluster synchronisation methods 25 * Management systems Operation of the gatekeeper 201 will depend upon requirements. For example, the gatekeeper 201 can be a single server or a cluster of servers. These servers may be located in a single place or in the case of a cluster of servers, they may be geographically disperse in a building, city, country or global configuration. A collection of geographically distributed servers will 30 hereinafter be referred to as a geograsp of servers.

WO 2008/086567 PCT/AU2008/000037 -47 In the case of a geograsp of servers, load sharing (balancing) is maintained by a cluster synchronisation method. Geograsps already exist in many forms, and are typically Domain Name Services (DNS) or virtual IP based. In this example, the system will accommodate redirection of gatekeeper 201 requests using IPv4 and/or IPv6. The terminal device will be prepared to accept 5 redirection commands via the network. Where a geograsp exists any gatekeeper 201 within that geograsp will be prepared via a private network dedicated to that geograsp to respond to a terminals request for authentication. In any case, the terminal initiates the requirement, and the first point of external contact is the gatekeeper 201 the details of which are stored in the service information stored in the identity device 10 420. Should the gatekeeper 201 be a member of a geograsp, that gatekeeper 201 will have the ability to modify the first contact information stored in the input device 410. Furthermore, should this first point of contact in the geograsp be non-operational, other points of contact that are stored in the identity device 420 will be contacted. The geograsp synchronises its database over its own private network. 15 The gatekeepers 201 are also used for user registrations. Registration is a process where the user enables their identity device 420 with the gatekeeper 201. This registration process will occur in the following manner: INITIAL REGISTRATION o The identity device 420 already contains the information necessary to register the 20 user. o The input device 410 already contains the information necessary to be registered. o Continuance - The provenance hierarchy (the governance authority) will always maintain Identity 420 and input device 410 registration should the manufacturer of the device cease to honour the registration process. 25 o Should the initial registration information become corrupted, the information for both the Input 410 and Identity device 420 can be reconstructed via the public storage store in the identity device 420. o An input device 410 cannot be registered without an identity device 420. o Whenever a device is "first - time" use, the device cannot be used until registration is 30 completed. The device will continue to prompt until registration is successful. o Where the unique event of both devices not being registered occurs, the identity device 420 will be coupled with the input device 410 and the identity device will be registered first. This registration will not be completed until the input device 410 has WO 2008/086567 PCT/AU2008/000037 -48 also been registered - during the same session and the registrants identity device 420 information has been stored in the input device 410. * SERVICE REGISTRATION o A user determines what service they require (A user can be an individual or a 5 corporation etc..) o The user knows a publicly published website. o Reception of registration information can be via a method based upon an "off-line" method. Typically, using today's technologies this method may be: - Download a unique file from the web site to the public storage are of an 10 identity device 420 - Receive a unique file from the web site on a mobile device (phone, other data device) via the public phone system = Receive a unique file from the web site via email o The input device 410 will only function as an input device 410 in concert with an 15 identity device 420. This characteristic is reciprocated. o Input devices 410 are only ever registered with their manufacturers respective gatekeeper 201. There is an association stored in this gatekeeper 201 between the input device 410 and the registering identity device 420. o Assuming the input device 410 is registered, the unique service file is loaded into the 20 public storage area of the identity device 420 using a public port on the terminal. o The identity device 420 is then removed from the public port and coupled with the input device 410. o (It should be noted that the public port and Provenance port of the identity device 420 may be physically the same port. They may alternatively be different physical ports. 25 In either case, the identity device 420 cannot work with both interfaces simultaneously. Attempting to do so may corrupt the device.) o After user authentication, the input device 410 downloads the unique service file and "Services" from the identity device 420 and the input device 410 then "reconstructs" the "Services" file and returns the new form of the "Services" file to the identity 30 device 420. * NORMAL USE o The gatekeeper 201 "listens" using an appropriate communications port to the communications networks for valid identity registrants requiring access to a gateway 202 WO 2008/086567 PCT/AU2008/000037 - 49 o The gatekeeper 201, having received a request, responds allowing the remote terminal communications to check provenance. o The gatekeeper 201 checks the provenance of the user, identity device 420 and input device 410 in the following manner: 5 - The user has been identified to the gatekeeper 201 during the service registration process. The real user identity is only known to the registrant. In the case of a corporate user, it makes sense for the corporation to know the real identity of the user. - The identity device 420 - if not already registered in the gatekeeper 201 10 database, the gatekeeper 201 contacts the manufacturers database, and establishes the provenance of the identity device 420 from the data supplied via the input device 410. - The input device 410 - if not already registered in the gatekeeper 201 database, the gatekeeper 201 contacts the manufacturers database, and 15 establishes the provenance of the input device 410 from the data supplied by the input device 410. An input device 410 cannot contact the gatekeeper 201 without being conjoined with an identity device 420. o The gatekeeper 201 requests the gateway 202 to allow a new session directly between the input device 410 and the gateway 202. 20 o If the gateway 202 allows the request, the gatekeeper 201 passes a unique data string, described in more detail in Appendix C to the input device 410. o Having established provenance, the gatekeeper 201 passes the unique data string received from the gateway 202 to the input device 410. o Once the gatekeeper 201 has ensured terminal to gateway 202 communications, the 25 gatekeeper 201 retires from the process. If the input device 410 fails to communicate with the gateway 202 the communications may cease and the process may restart. o The gatekeeper 201 maintains a watch of the link between the terminal and the gateway 202 in the following manner. The gatekeeper 201, having delivered the required information from the gateway 202 to the input device 410 awaits either a 30 "connection established" signal from the gateway 202 or a "connection cannot be established" signal from the input device 410.

WO 2008/086567 PCT/AU2008/000037 - 50 Appendix C Operation of a gateway 202 will now be described in more detail. The gateway 202 is a device that facilitates communications between the terminal and the applications server 203. 5 The gateway 202 is a secure device. All data files on the device are encrypted and secure. The gateway 202 is a computer server or cluster of computer servers that share a common purpose. Their purpose is to facilitate purposeful allowance of communications between terminals 204 and applications servers 203. A single gateway 202 can have a single CPU, multiple CPUs, multiple motherboards with single 10 CPUs, multiple motherboards with multiple CPUs. These hardware devices may be capable of virtualisation of unique operating systems. The gateway 202 model is scalable both in the following terms: " Security o Physical 15 o Logical o Lower security models will be cheaper o Enterprise models * Power " Hardware based 20 * Virtual Machine based The gateway 202 can consist of a single operating system or a home operating system with multiple virtual orthogonal operating systems. Physical security is maintained by combining physical mechanisms and logical processes. The gateway 202 typically has four or more communications ports for the following purposes: 25 * External port through which communications to the remote user systems are directed. The number of external ports in place is dependent upon the system requirements.

WO 2008/086567 PCT/AU2008/000037 -51 " The gatekeeper 201 port through which secure communications with the gatekeeper 201 are directed. Furthermore, the gateway 202 receives software updates, maintains audit processes and maintains communications in order to allow registration checks to take place. " Application server port through which the gateway 202 communicates with the application 5 server. There may be more than one Application server port. * Management port through which secure communications allow high level management functions. " When required, a gateway 202 may have a port dedicated to maintaining communications with other cluster members. 10 The gateway 202 may also be maintained from an industry standard console consisting of an external keyboard, pointing device and a monitor. The gateway 202 typically maintains software processes such as: * Communications processes with multiple remote user systems * Communications processes with other gateway 202s in the cluster 15', Communications processes with gatekeeper 201s * Communication processes with auditing systems via gatekeeper 201 * Communications processes with licensing systems via gatekeeper 201 * Communications systems with management systems * Communications systems with console systems 20 e Security systems for encrypting communications * Security systems for encrypting databases * Security systems for ensuring device physical integrity * Security systems for ensuring operating systems integrity * Database systems for gateway 202s 25 e Database systems for system integrity * Encryption tables * Audit systems * Cluster synchronisation methods * Management systems 30 The gateway 202 typically performs the following functions: " Maintain communications with the gatekeeper 201 * Maintain communications with the applications server WO 2008/086567 PCT/AU2008/000037 - 52 * Expect encrypted communications with the terminal " Encrypt/decrypt communications with gatekeeper 201 and terminal * Generate unique codes that will be relayed via the gatekeeper 201 for the input device 410 In general, to help ensure security the gateway 202 can only be upgraded/commissioned/provenanced 5 via a gatekeeper 201. In use, the gateway 202 facilitates communications between the applications server 203 and the terminal 204. Direct communications with the applications server 203 is not possible. Communications between the terminal 204 and the gateway 202 is controlled by the gatekeeper 201. The gateway 202 maintains constant communications with the gatekeeper 201. 10 When the gatekeeper 201 signals the gateway 202 that a new gateway 202 session is required, the same encryption key is sent from the gatekeeper 201 to both the input device 410 and the gateway 202. The gateway 202 in retum, generates a unique access key which is relayed via the gatekeeper 201 to the input device 410. The gateway 202 is now in a position to expect communications using a unique access key from a 15 particular input device 410 using a unique encryption key. One implementation of the gateway 202 is as a single operating system server, which is typically based on IP sockets. Another implementation involves the "base" server "popping" (generating) virtual machines as required. Popping Virtual Machines involves the following: 20 e When the gateway 202 receives a request for a session from the gatekeeper 201, the gateway 202 does the following: o Generates a unique access key o Starts a virtual machine that will only respond to that unique access key o Sends the unique access key to the input device 410 via the gatekeeper 201 25 o In an IPv6 configuration, this unique access key will involve a unique IP number o In an IPv4 configuration, this unique access key will involve Network Address Translation and a unique IP number o Once the session is completed, the virtual machine shuts down.

WO 2008/086567 PCT/AU2008/000037 - 53 APPENDIX D An example of a specific authentication process will now be described. For the purpose of this example, the identity device 420 contains the following data: 1) Secret information 5 a) sequence number - this is rewritten each time the identity device 420 is used b) user registration information (user identity) c) private key of identity device 420 d) encryption code sheet e) other registration information 10 2) Public information a) encrypted executable to download to and run on the input device 410 which is rewritten each time the identity device 420 is used b) public key of manufacturer - this may be periodically rewritten as required c) public key of service - this is rewritten each time the identity device 420 is used 15 d) provenance information in cleartext (ROM) fixed e) other registration information 3) Provenance Information - encrypted by public key of manufacturer 4) executable code 20 The input device 410 contains the following data: 1) Secret information a) sequence number b) user registration information (user identity) c) private key of device 25 d) encryption code sheet e) other registration information 2) Public information a) Public key of manufacturer b) Provenance information in cleartext (ROM) 30 3) Provenance information - encrypted by public key of manufacturer. 4) Executable code The process for authenticating is as follows: WO 2008/086567 PCT/AU2008/000037 -54 * When the input device 410 and identity device 420 are first "coupled" (joined by a communications method), and mutual provenance has been established using the public provenance information, the input device 410 can now accept a user passphrase. The algorithm (or part thereof) to establish this base level of provenance is always present in input 5 device 410, and may be present in identity device 420 if identity device 420 has a CPU and encryptor. (the term encryptor always refers to a process that can encrypt and decrypt.) * Whilst a biometric can be used at the first authentication level, an exact passphrase is required to produce/decrypt the secret information. Accordingly, as current technology cannot generate an exact passphrase (signature) from biometric information, a biometric should be 10 accompanied with a passphrase. However, if an exact passphrase can be generated from biometric information, this alone could be used. * Having received the user passphrase, input device 410 downloads the encrypted executable (unique every session), the public provenance and public keys for the manufacturer (normally fixed) and service list from identity device 420. The encrypted executable was created and 15 stored during the last successful logon interchange with the gatekeeper 201. The input device 410 uses a new service public key generated by the gatekeeper 201. The encrypted executable can be fully downloaded from the gatekeeper 201 together with the new service public key, sequence number and other secret data, or it can be concocted using these parameters using the program in the input device. The encrypted executable and public key for the service 20 changes with every successful authentication between the gatekeeper 201 and (any) input device 410/identity device 420. The input device 410 passes this information on to be stored in the identity device 420 and retains no knowledge or storage of the encrypted executable and public key for the service. * The identity device 420 encrypted executable, the identity device 420 sequence number and 25 the identity device 420 public key of service are "re-encrypted" after successful authentication of the input device 410/identity device 420 provenance and user passphrase #2 by the gatekeeper 201. This process happens every time a service is used. There is a separate identity device 420 encrypted executable, identity device 420 sequence number and identity device 420 public key of service for each service. The identity device 420 stores a different 30 encrypted executable, sequence number and public key of service for each service. " The input device 410 is programmed to decrypt the identity device 420 executable code using a key concocted from the user passphrase, the identity device 420 sequence number, the identity device 420 public key from manufacturer and the input device 410 provenance information.

WO 2008/086567 PCT/AU2008/000037 -55 0 The executable code is written differently for each service. Consequently if the encryption key is cracked for one service, it cannot be cracked for other services stored in the identity device 420. * When the encrypted executable contained in identity device 420 is downloaded to input device 5 410 and is decrypted, it is then used by input device 410 to unlock the secret memory in the identity device 420. * A mutually exclusive split key system between input device 410 and identity device 420 may be used for certain services. The user sets this service to only be allowed when paired on these input device's 410 using this singular particular identity device 420. This system is used 10 if the user wants to isolate the use of a particular identity device 420 to certain input devices 410. * Two or more identity device's 420 may be required to access some services. In this case the input device 410 may have to accommodate more than one identity device 420. * The public key for the input and identity devices 410, 420 is established at provenance and 15 can only be reset by resetting the respective input and identity devices 410, 420 with their respective "home" (manufacturers) provenance gatekeeper 201 s. * Each gatekeeper 201 may keep different records for each individual registrant. Each gatekeeper 201 typically only contains the "details" of registrants. These details are only of interest to the registrant. The gatekeeper 201, does not need to know the proper identity of the 20 registrant. Registration details should not be shared amongst gatekeeper 201 s. * As the input device (input device 410) does not know every gatekeeper 201 (when new, both the input device 410 and identity device 420 may only know their respective manufacturers gatekeeper) the identity device 420 must store the appropriate data in a secure manner for every gatekeeper 201 with which it has registered. 25 0 The gatekeeper 201 must be able to communicate with a manufacturers database in order to ensure input device 410 provenance allowing registration of that input device 410. * The software agent accommodating the interchange between input device 410 and the gatekeeper 201 takes no part in decoding, it merely passes the data traffic between the input device 410 and the gatekeeper 201 via the untrusted device 204. 30 e Initial registration with a gatekeeper 201 may involve the identity device 410 provenance, the software agent, and some third party "return to user - communications method" (sms, email, special website using https, etc.) that gives the user a special permission to create an account on that gatekeeper 201 system.

Claims

THE CLAIMS DEFINING THE INVENTION ARE AS FOLLOWS:

1 ) A method of performing a secure interaction, the method including, in an input device: a) performing a checking operation using first information, to thereby confirm input device integrity; b) providing second information received from a user, to a gatekeeper, the gatekeeper being responsive to the second information to: i) perform authentication; and, ii) establish communication between the input device and a service provider in response to a successful authentication; and, c) communicating with the service provider in accordance with user input to thereby perform the secure interaction.

2) A method according to claim 1, wherein the input device is connected to an identity device, and wherein the method includes, in the input device, performing the checking operation at least in part using information provided on the identity device. 3) A method according to claim 1 or claim 2, wherein the method includes, in the input device: a) receiving the first information from the user; b) accessing first data from a first store at least partially using the first information; and, c) in an internal processing system, using the first data to confirm input device integrity.

4) A method according to claim 3, wherein the first data is stored as encrypted first data, and wherein the method includes, in the internal processing system, decrypting the first data using the first information.

5) A method according to claim 4, wherein the method includes, in the input device: a) accessing an algorithm from a store; b) generating a first key at least in part using the first information and the algorithm; and, c) decrypting the first data using the first key.

6) A method according to any one of the claims 3 to 5, wherein the method includes, in the input device: a) accessing second data from a second store; and, b) in the internal processing system, comparing at least some of the first and second data to thereby confirm input device integrity.

7) A method according to any one of the claims 1 to 6, wherein the input device is connected to an identity device via a connection, and wherein the method includes, in the input device accessing at least one of first and second stores via the connection.

8) A method according to claim 7, wherein the method includes, in the input device, updating at least one of a sequence number and an executable file stored in the identity device. 9) A method according to claim 8, wherein the method includes, in the input device, receiving at least one of an updated sequence number and an updated executable file, from the gatekeeper.

10) A method according to any one of the claims 7 to 9, wherein the method includes, in the input device: a) authenticating the identity device; and, b) performing the checking operation in response to successful authentication.

H) A method according to any one of the claims 7 to 10, wherein the method includes, in the input device: a) checking the integrity of the identity device; and, b) generating an indication of the integrity using an indicator.

12) A method according to any one of the claims 1 to 1 1, wherein the input device is coupled to a computer system, and wherein, the method includes, in the input device and in response to confirming the integrity of the input device: a) determining a service list from a store; and, b) transferring the service list to the computer system, the computer system being responsive to the service list to display a list of available services.

13) A method according to claim 12, wherein the method includes, in the input device: a) determining a service indication in accordance with a user input; and, b) transferring the service indication to the computer system, the computer system being responsive to the service indication to: i) determine a gatekeeper; and, ii) enable communication between the gatekeeper and the input device.

14) A method according to any one of the claims 1 to 13, wherein the method includes, in the input device, communicating with the gatekeeper via a computer system having a software agent installed thereon.

15) A method according to claim 14, wherein the method includes, in the input device: a) communicating with a computer system to determine if a software agent is installed; and, b) if no software agent is installed; i) accessing a software agent from a second store; and, ii) transferring the software agent to the computer system.

16) A method according to any one of the claims 1 to 15, wherein the method includes, in the input device: a) receiving the second information from the user; b) receiving a second key from the gatekeeper; c) encrypting the second information using the second key; and, d) transferring the encrypted second information to the gatekeeper, the gatekeeper being responsive to: i) decrypt the encrypted second information; and, ii) compare the second information to predetermined second information to thereby perform the authentication.

17) A method according to any one of the claims 1 to 16, wherein the method includes, in the input device: a) mutually authenticating the gatekeeper; and, b) transferring the second information in response to a successful mutual authentication. 18) A method according to claim 17, wherein the method includes, in the input device: a) accessing a fourth key from the first store; and, b) performing the mutual authentication at least in part using the fourth key.

19) A method according to any one of the claims 1 to 18, wherein the method includes, in the input device: a) receiving connection data from the gatekeeper in response to a successful authentication; and, b) communicating with the service provider using the connection data.

20) A method according to claim 19, wherein the connection data includes a resource locator, and wherein the method includes, in the input device, providing the resource locator to a computer system, the computer system using the resource locator to establish the connection with the service provider.

2I) A method according to claim 19 or claim 20, wherein the method includes, in the input device: a) determining a second session key; and, b) communicating with the service provider at least in part using the second session key.

22) A method according to any one of the claims 1 to 21 , wherein the method includes, in the input device, communicating with the service provider via a gateway.

23) A method according to any one of the claims 1 to 22, wherein the method includes, in the input device: a) receiving user inputs; b) encrypting the user inputs; and, c) transferring the encrypted inputs to a gateway, the gateway being responsive to decrypt the inputs and provide the inputs to the service provider.

24) A method according to any one of the claims 1 to 23, wherein the method includes, in the input device: a) performing encryption using at least one encryptor; and, b) causing an indication of an encryptor status to be displayed using at least one of: i) an indicator provided on the input device; and, ii) a computer system. 25) A method according to any one of the claim 1 to 24, wherein the method includes, in the input device, using an indicator for indicating at least one of: a) integrity and/or authenticity of an identity device; b) integrity and/or authenticity of the gatekeeper; c) integrity and/or authenticity of a gateway; d) success or otherwise of authentication; and, e) success or otherwise of agent initialisation. 26) A method according to any one of the claims 1 to 25, wherein the method further includes having the user undergo authentication with the service provider. 27) A method according to any one of the claims 1 to 26, wherein the method is performed at least in part using an identity device owned by a user, to thereby allow the user to establish a trust relationship with the gateway. 28) A method according to any one of the claims 1 to 27, wherein the method uses user centric security.

29) A method according to claim 28, wherein the user centric security facilitates the service provider's services in a manner suitable to the service provider's security model.

30) A method according to claim 28 or claim 29, wherein the method includes, having the user self validate using special hardware and software first locally and then remotely.

3 I) A method according to any one of the claims 1 to 30, wherein the method assumes a computer system to which the input device is connected is untrusted. 32) A method according to any one of the claims 1 to 31 , wherein the method uses a secure interaction device formed from a secure input device and a secure user identity device. 33) A method according to claim 32, wherein the method creates a secure connection between the interaction device and a gateway mediated by a trusted third party device.

34) A method according to any one of the claims 1 to 33, wherein the method ensures provenance of the local hardware, local software, keys, and remote devices and their software to a user.

35) A method according to any one of the claims 1 to 34, wherein the method separates and updates encryption keys in a one-time manner.

36) A method according to any one of the claims 1 to 35, wherein the first data includes encrypted provenance information, and wherein second data includes public provenance information.

37) Apparatus for performing a secure interaction, the apparatus including an input device for: a) performing a checking operation using first information, to thereby confirm input device integrity; b) providing second information received from a user, to a gatekeeper, the gatekeeper being responsive to the second information to: i) perform authentication; and, ii) establish communication between the input device and a service provider in response to a successful authentication; and, c) communicating with the service provider in accordance with user inputs to thereby perform the secure interaction.

38) Apparatus according to claim 37, wherein the input device includes: a) an input, for receiving inputs from a user; b) a connector for allowing connection to a computer system; and, c) an internal processing system for at least one of: i) controlling the operation of the input device; ii) interpreting inputs received via the input device; and, iii) performing encryption; iv) communicating with at least one of:

(1) a processing system;

(2) an identity device;

(3) a gateway; and,

(4) a gatekeeper. 39) Apparatus according to claim 38, wherein the input device includes an indicator for indicating at least one of: a) integrity and/or authenticity of the identity device; b) integrity and/or authenticity of the gatekeeper; c) integrity and/or authenticity of the gateway; d) success or otherwise of authentication; and, e) success or otherwise of agent initialisation.

40) Apparatus according to any one of the claims 37 to 39, wherein the input device includes a connector for allowing connection to an identity device.

41) Apparatus according to any one of the claims 37 to 10, wherein the input device includes an encryptor for encrypting communication.

42) A method according to any one of the claims 37 to 41, wherein the input device performs the method of any one of the claims 1 to 36.

43) A method of performing a secure interaction, the method including, in an identity device, providing first data to an input device from a first store, the input device being responsive to transfer the first data to an internal processing system, the internal processing system being responsive to use the first data to confirm input device integrity.

44) A method according to claim 43, wherein the method includes, in the identity device, providing second data to an input device from a second store, the input device being responsive to transfer the second data to the internal processing system, the internal processing system being responsive to use the first and second data to confirm input device integrity.

45) A method according to claim 43 or claim 44, wherein the first data is stored as encrypted first data to thereby allow the first data to be decrypted at least in part using first information.

46) A method according to any one of the claims 43 to 45, wherein the first store stores an algorithm, the first information and the algorithm being used to determine a first key for decrypting the first data.

47) A method according to any one of the claims 43 to 46, wherein the method includes, in the identity device, using an indicator for indicating at least one of: a) integrity and/or authenticity of the input device; b) integrity and/or authenticity of a gatekeeper; c) integrity and/or authenticity of a gateway; d) success or otherwise of authentication; and, e) success or otherwise of agent initialisation.

48) A method according to claim 43 to 47, wherein the method includes, in the identity device, interacting with an input device to perform the method of any one of the claims 1 to 36.

49) Apparatus for performing a secure interaction, the apparatus including a first store for storing first data, the first data being provided to an input device, the input device being responsive to transfer the first data to an internal processing system, the internal processing system being responsive to use the first data to confirm input device integrity. 50) Apparatus according to claim 49, wherein the identity device includes a second store for storing second data, the second data being provided to an input device, the input device being responsive to transfer the second data to the internal processing system, the internal processing system being responsive to use the first data to confirm input device integrity.

51 ) Apparatus according to claim 50, wherein the second store stores at least one of: a) provenance information; and, b) a copy of an agent application.

52) Apparatus according to any one of the claims 49 to 51 , wherein the first store stores at least one of: a) encrypted provenance information; b) encrypted first information; c) an encrypted sequence number; d) encrypted provenance information; e) an encrypted service list; f) a first encryption key; and, g) a fourth encryption key.

53) Apparatus according to any one of the claims 49 to 52, wherein the identity device includes a connector for connecting to the input device.

54) Apparatus according to any one of the claims 49 to 53, wherein the apparatus includes an indicator for indicating at least one of: a) integrity and/or authenticity of the input device; b) integrity and/or authenticity of a gatekeeper; c) integrity and/or authenticity of a gateway; d) success or otherwise of authentication; and, e) success or otherwise of agent initialisation. 55) Apparatus according to any one of the claims 49 to 54, wherein the apparatus is for performing the method of any one of the claims 43 to 48.

56) A method of performing a secure interaction, the method including, in a gatekeeper: a) receiving second information from an input device; b) performing authentication using both the second information and user information; and, c) establishing communication between the input device and a service provider in response to a successful authentication, the input device communicating with the service provider in accordance with user inputs to thereby perform the secure interaction.

57) A method according to claim 56, wherein the method includes, in a gatekeeper: a) providing a second session key to the input device, the input device being responsive to encrypt the second information using the second session key; b) receiving encrypted second information; c) decrypting the encrypted second information; and, d) comparing the second information to predetermined second information to thereby perform the authentication. 58) A method according to claim 57, wherein the method includes, in the gatekeeper: a) mutually authenticating the input device; and, b) providing the second session key in response to a successful mutual authentication.

59) A method according to any one of the claims 56 to 58, wherein the method includes, in the gatekeeper, communicating with the input device via a computer system. 60) A method according to any one of the claims 56 to 59, wherein the method includes, in the gatekeeper, providing connection data to the input device in response to a successful authentication, the connection data being used to establish a secure connection between the gateway and the input device. 6I ) A method according to claim 60, wherein the method includes, in the gatekeeper, receiving the connection data from a gateway.

62) A method according to claim 60 or claim 61 , wherein the connection data includes a resource locator, and wherein the input device is responsive to the resource locator to provide the resource location to a computer system, the computer system using the resource locator to establish communication with the gateway.

63) A method according to any one of the claims 56 to 62, wherein the method includes, in the gatekeeper: a) determining a service indication in accordance with a user input provided via the input device; and, b) determining a gateway using the service indication.

64) A method according to any one of the claims 56 to 63, wherein the method includes, in the gatekeeper, performing authentication of an input device performing the method of any one of claims 1 to 36.

65) Apparatus for performing a secure interaction, the apparatus including a gatekeeper for: a) receiving second information from an input device; b) receiving user information via an input device; c) performing authentication using the second information; and, d) establishing communication between the input device and a service provider in response to a successful authentication, the input device being responsive to communicate with the service provider in accordance with user inputs to thereby perform the secure interaction.

66) Apparatus according to claim 65, wherein the gatekeeper is a suitably programmed processing system.

67) Apparatus according to claim 65 or claim 66, wherein the apparatus is for performing the method of any one of the claims 56 to 64. 68) A method for performing a secure interaction, the method including, in a gateway: a) in response to a successful authentication by a gatekeeper, generating connection data; b) transferring the connection data to the gatekeeper, the gatekeeper being responsive to provide the connection data to an input device, thereby allowing a connection to be established between the input device and a service provider; and, c) transferring communication between the input device and the service provider. 69) A method according to claim 68, wherein the method includes, in the gateway: a) generating the resource locator in accordance with a service selection, the service selection being indicative of a selected service provider; and, b) generating the connection data using the resource locator, thereby allowing an input device to establish a connection via a computer system with the selected service provider via the gateway.

70) A method according to claim 69, wherein the resource locator has a limited life span.

7I) A method according to any one of the claims 68 to 70, wherein the method includes, in the gateway: a) receiving a connection request from a computer system, the connection request being at least partially based on a resource locator; b) establishing a connection in response to the received connection request.

72) A method according to any one of the claims 68 to 71, wherein the method includes, in the gateway: a) determining if the resource locator has expired; and, b) establishing the connection if the resource locator has not expired.

73) A method according to any one of the claims 68 to 72, wherein the method includes, in the gateway: a) receiving encrypted communication from the input device; b) decrypting the encrypted communication; and, c) transferring the decrypted communication to the service provider.

74) Apparatus for performing a secure interaction, the apparatus including a gateway for: a) in response to a successful authentication by a gatekeeper, generating connection data; b) transferring the connection data to the gatekeeper, the gatekeeper being responsive to provide the connection data to an input device, thereby allowing a connection to be established between the input device and a service provider; and, c) transferring communication between the input device and the service provider.

75) Apparatus according to claim 74, wherein the gatekeeper is a suitably programmed processing system. 76) Apparatus according to claim 74 or claim 74, wherein the apparatus is for performing the method of any one of the claims 68 to 73. 77) A method of performing a secure interaction, the method including: a) performing a checking operation using first information provided via an input device, to thereby confirm input device integrity; b) performing remote authentication of second information provided via the input device; c) establishing a connection with a service provider in response to a successful authentication; d) performing secure interaction with the service provider using the established connection.

78) A method according to claim 77, wherein the method includes: a) connecting an identity device to the input device; and, b) performing the checking operating at least in part using first data stored on the identity device.

79) A method according to claim 77 or claim 78, wherein the method includes, performing the remote authentication in a gatekeeper, the gatekeeper being used to establish a connection between the input device and the service provider.

80) A method according to any one of the claims 77 to 79, wherein the method includes, establishing the connection via a gateway, the gateway and input device being adapted to encrypt information transferred therebetween.

8I) A method according to any one of the claims 77 to 80, wherein the method is performing using an input device performing the method of any one of the claims 1 to 36.

82) Apparatus for performing a secure interaction, the apparatus including: a) an input device; b) a processing system for performing a checking operation using first information provided via the input device, to thereby confirm input device integrity; c) a gatekeeper for: i) performing remote authentication of second information provided via the input device; and, ii) establishing a connection with a service provider in response to a successful authentication, the connection being used to perform secure interaction with the service provider using inputs supplied via the input device.

83) Apparatus according to claim 82, wherein the apparatus includes an identity device for storing first and second data, and where the input device is responsive to connection to the identity device to thereby retrieve at least some of the first and second data.

84) Apparatus according to claim 82 or claim 83, wherein the apparatus includes a gateway, the connection being established using the gateway.

85) Apparatus according to claim 84, wherein the input device is for encrypting user inputs, and wherein the gateway is for: a) decrypting the user inputs; and, b) providing the decrypted user inputs to the service provider.

86) Apparatus according to any one of the claims 82 to 85, wherein the apparatus is for performing the method of any one of the claims 77 to 81. 87) A method of performing a secure interaction, the method including: a) verifying operation of an input device at least in part using an identity device; b) performing remote authentication at least in part using the identity device; and, c) establishing a connection with a service provider in response to a successful authentication.

88) A method according to claim 87, wherein the method includes: a) connecting the identity device to the input device; b) providing first information using the input device, the input device being responsive to the first information to: i) retrieve first and second data from first and second stores in the identity device, at least in part using the first information; ii) providing the first and second data to a processing system, the processing system using the first and second data to verify the operation.

89) A method according to claim 87 or claim 88, wherein the method includes, providing second information via the input device, the input device being responsive to provide the second information to a gateway, the gateway using the second information to perform the remote authentication.

90) A method according to any one of the claims 87 to 89, wherein the method includes establishing the connection via a gateway.

9I ) A method according to any one of the claims 87 to 90, wherein the method is performing using a input device for performing the method of any one of the claims 1 to 36. 92) Apparatus for performing a secure interaction, the apparatus including: a) an input device; b) an identity device; c) a processing system for verifying the operation of the input device using the identity device; and, d) a gateway for authentication the user, the gateway being responsive to a successful authentication to establish a connection with a service provider.

93) Apparatus according to claim 92, wherein the apparatus is for performing the method of any one ofthe claims 87 to 91.