Methods and devices for performing secure electronic transactions

TECHNICAL FIELD

0001The present invention is related to a method for performing secure electronic transactions. The invention is further related to a corresponding system, a corresponding server computer, a corresponding hardware device, a corresponding client computer and a corresponding computer program.

BACKGROUND OF THE INVENTION

0002Current Internet authentication processes often utilize Public Key Infrastructure (PKI). Especially in the presence of malicious software on a Personal Computer (PC) of a user it may be uncertain whether the user is connected to the desired server computer he wants to transact with, e.g. a desired banking server. One known method to prevent adversary attacks asks the user to check server certificates that have been issued by a trusted entity to the server operator. As this is cumbersome, many users refrain from performing such a server certificate check. Another known approach uses PKI-technology in combination with smart cards. However, the user does not have full control over what the smart card actually does, e.g. what it signs or where it connects to. This is caused by the fact that Internet connections can be compromised by men-in-the-middle attacks, worms or viruses running on the PC of the user. Furthermore, keyboard logging software and display-altering software can be used to trick the user into working with a bogus website, e.g., to transmit some money to a bank account of an adversary.

0003The above described approaches rely at some point in the process on a step in which the server displays some confidential/secret information on the PC and/or on a step in which the user enters some confidential/secret information on the PC. This is true even for secure smart card readers featuring a display and keyboard. The information that a secure smart card reader displays is still controlled by software running on the PC.

0004<patcit id="pcit0001" dnum="US6895502B1"><text>US 6895502 B1</text></patcit> discloses a method for securely displaying and securely confirming that a request to access a resource on a server computer was actually requested by the client user. In response to the request the server computer sends an encrypted challenge to a secure environment that allows the client user to check and confirm that he made the corresponding request.

0005<patcit id="pcit0002" dnum="US5596718A"><text>US 5 596 718</text></patcit> discloses a secure user interface created by inserting a trusted path subsystem between input/output devices of a workstation and the workstation itself. The trusted path subsystem is invoked manually by the user and utilizes the display of the workstation for displaying a trusted window.

0006<patcit id="pcit0003" dnum="US20040065728A1"><text>US 2004/0065728 A1</text></patcit> discloses an integrated circuit card comprising a connection and communication interface designed to set up a communication with a host unit in the form of a communication device. The integrated circuit card further comprises security software designed to cooperate with cryptographic software means to produce a set of security operations on the received data.

0007<patcit id="pcit0004" dnum="US20070198825A1"><text>US 2007/0198825A1</text></patcit> discloses a secure terminal as a PC local peripheral that executes SSL client software, protocol software and application software. Server certificates are verified against values pre-loaded into the secure terminal and the user and the secure terminal are mutually authenticated.

0008The document "Smartcard Firewalls Revisited", by Poehls and Posegga, XP 0190029955, discloses the use of smartcards as secure endpoints in computer transactions.

0009It is an object of the invention to provide other solutions for performing electronic transactions in a secure way.

0010It is a further object of the invention to provide solutions for performing electronic transactions that can be implemented in a cost efficient way.

0011It is a further object of the invention to provide solutions for performing electronic transactions with improved ease of use.

0012It is a further object of the invention to provide solutions for performing electronic transactions in a secure way that can utilize existing server infrastructures without significant adaptation of the servers.

0013It is a further object of the invention to provide solutions for performing electronic transactions in a secure way that can utilize existing stream authentication protocols such as SSL/TLS.

SUMMARY AND ADVANTAGES OF THE INVENTION

0014The present invention is directed to methods and hardware devices as defined in the independent claims. Further embodiments of the invention are provided in the appended dependent claims.

0015According to a first aspect of the invention there is provided a method according to claim 1.

0016The method according to this aspect of the invention offers enhanced security of the electronic transactions. An electronic transaction may be e.g. an electronic payment, an electronic money transfer, an electronic order or any other transfer of confidential, private or security sensitive information such as logon information.

0017Furthermore, the method according to this aspect of the invention has the advantage that it can be implemented in a flexible, efficient and economic way. A further advantage of the method is that it can be efficiently and economically added to existing systems.

0018The hardware device works as an interface between the server computer and the client computer. In other words, during the electronic transaction only the hardware device communicates logically directly with the server computer. This allows for observing, evaluating, parsing and controlling the communication between the client computer and the server computer. Messages or data that the client computer wants to send to the server computer are denoted as client requests, while messages or data that the server computer sends to the client computer are denoted as server responses. The hardware device can decrypt the server responses and may forward them to the client computer. The client computer comprises a client computer display that may present the decrypted server response to a user. The user may then interact with the client computer by means of a client computer input unit, e.g. by means of a keyboard and/ or a mouse, and initiate a client request. The client computer sends the client request to the hardware device and the hardware device parses the client request for predefined transaction information. In other words, the hardware device analyses the client requests and checks whether it contains any predefined transaction information. Such predefined transaction information is in particular security sensitive, private and/or confidential information, such as credit card numbers, transaction numbers (TAN), bank account numbers, payment data, payment amounts etc. The pre-definition can be made application specific and/or customer specific. As an example, a bank that offers online banking can predefine which information to be transferred by the client to the bank shall be considered as predefined transaction information. Furthermore, the bank may offer online banking services with different security levels. For each security level the predefined transaction information may be adapted.

0019The term client computer is understood in a broad sense. A client computer could be e.g. a laptop PC, a desktop PC, a mobile phone, a Personal Digital Assistant (PDA) or any other electronic device by means of which a user may perform electronic transactions. The term server computer is understood in a broad sense as well. It may be any electronic device with which a client computer wants to perform an electronic transaction with.

0020If the client request does not contain any predefined transaction information, the hardware device may encrypt and forward the client request to the server computer by means of the first communication protocol. If the client request contains predefined transaction information, the hardware device may present the predefined transaction information to the user on the display of the hardware device. This enables the user to check whether the predefined transaction information is correct. Furthermore, the user can compare the transaction information that is displayed on the display of the client computer with the transaction information that is displayed on the display of the hardware device. This facilitates the detection of differences which may be introduced by man-in-the-middle attacks. If the user detects a difference between the transaction information displayed on the client display and the transaction information displayed on the hardware device display, this is an indication that malicious software is running on the client computer and has altered the transaction information entered by the user via the client computer input unit.

0021The hardware device display may be embodied in various ways. The hardware device display may be embodied in various devices or tools operable to present the transaction information to a user. Examples for a hardware device display are Liquid Crystal Displays (LCD), Light Emitting Diode (LED)-Displays, plasma displays or projectors, e.g. LCD or laser projectors.

0022If the predefined transaction information is not correct, the user can cancel or not confirm the transaction. Then the hardware device cancels the transaction. If the user has verified that the predefined transaction information presented on the hardware device display is correct, he may confirm the transaction. Upon confirmation the hardware device encrypts the predefined transaction information and sends it to the server computer by means of the first communication protocol.

0023The hardware device interprets it as a confirmation if the user does not cancel the transaction within a predefined time period, e.g. within 1 minute.

0024The first communication protocol is established and run as end to end communication between the hardware device and the server computer. The first communication protocol uses mutual authentication, i.e. the server computer authenticates itself to the hardware device and the hardware device authenticates itself to the server computer. The data transmission between the hardware device and the server computer is performed in encrypted form in order to provide a high degree of confidentiality.

0025According to an embodiment of the first aspect of the invention the method further comprises the steps of: <ul id="ul0001" list-style="dash" compact="compact"><li>running in a normal mode of operation a second communication protocol between a browser application of the client computer and the server computer,</li><li>running in a secure mode of operation the first communication protocol between the server computer and the hardware device,</li><li>routing in the secure mode of operation client requests from the browser application via a proxy application to the hardware device and from the hardware device via the proxy application to the server computer,</li><li>routing in the secure mode of operation server responses from the server computer via the proxy application to the hardware device and from the hardware device via the proxy application to the browser application.</li></ul>

0026The proxy application may be implemented as computer program running on the client computer and allows for an efficient implementation of the method. It performs the function of a switch that is functionally arranged between the hardware device, the browser application and the server computer.

0027In the normal mode of operation the user does preferably not exchange security sensitive information with the server computer. In the normal mode of operation the hardware device can be switched off or unplugged.

0028If during his browsing session the user wants to perform an electronic transaction which may involve the exchange of security sensitive information, the secure mode of operation is invoked. According to this embodiment of the invention, in the secure mode the first communication protocol is run between the server computer and the hardware device via the proxy application and the communication network. Furthermore, the communication between the browser application and the hardware device is performed via the proxy application.

0029According to an embodiment of the first aspect of the invention the method further comprises the steps of: <ul id="ul0002" list-style="dash" compact="compact"><li>running in the normal mode of operation the second communication protocol between the browser application of the client computer and the server computer via the proxy application of the client computer,</li><li>parsing client requests for a predefined set of client requests by the proxy application,</li><li>initiating the secure mode of operation by the proxy application upon detection of a predefined client request.</li></ul>

0030This is an efficient method to invoke the secure mode of operation in an automated way. The proxy application may automatically initiate the secure mode of operation without any user interaction. As an example, the predefined set of client requests may comprise a predefined set of Uniform Resource Identifiers (URI) or Uniform Resource Locators (URL) that identify resources of the server computer. Such resources may be e.g. one or more URLs of banks where the user has an account and/or one or more electronic commerce entities with whom the user wants to perform e-commerce or any entity with whom the user wants to perform electronic transactions. If the user types in one of these predefined URLs or URIs in his browser application, the proxy application detects it and initiates the secure mode of operation. The secure mode of operation may be e.g. initiated by means of sending an "initiate secure mode" signal to the hardware device.

0031In the normal mode of operation the proxy application forwards or routes respectively client requests directly from the browser application to the server computer via the communication network. In the other direction, server responses are sent via the communication network to the proxy application and forwarded directly from the proxy application to the browser application.

0032According to another embodiment of the invention the secure mode could be invoked manually by the user, e.g. by connecting the secure hardware device with the client computer.

0033According to an embodiment of the first aspect of the invention the method further comprises, before forwarding the decrypted server responses from the hardware device to the client computer, the steps of <ul id="ul0003" list-style="dash" compact="compact"><li>parsing the server responses for predefined transaction information by the hardware device,</li><li>forwarding server responses that do not contain any predefined transaction information to the client computer by the hardware device,</li><li>displaying the predefined transaction information upon detection in a server response on the hardware device display of the hardware device,</li><li>forwarding the server response containing the predefined transaction information to the client computer if a user confirmation is received,</li><li>canceling the electronic transaction if no user confirmation is received.</li></ul>

0034Parsing the server responses in addition to parsing the client requests provides enhanced functionality and applications. The predefined transaction information of server responses can be displayed on the hardware device display for the attention of the user. The predefined transaction information of the server responses may e.g. comprise warning messages of the server computer which could be displayed on the hardware device display. Furthermore, the predefined transaction information of the server responses may be server challenges to the user or any other security sensitive information from the server computer to the user. This has the advantage that the user can check such predefined transaction information of the server even if malicious software running on the client computer prevents that the predefined transaction information is displayed on the client computer display or if the malicious software manipulates the view on the client computer display.

0035According to a further embodiment of the first aspect of the invention the first communication protocol comprises a network layer comprising a protocol according to the Secure Sockets Layer (SSL)-standard or according to the Transport Layer Security (TLS)-standard and a protocol according to the Transmission Control Protocol/Internet Protocol (TCP/IP)-standard.

0036These protocols are broadly applicable and widespread. The method according to this aspect of the invention can use these protocols without any need for adaptation. This allows implementing the method according to this aspect of the invention in a cost efficient way. The SSL or TLS layer runs above the TCP/IP-layer and provides the functionality of server authentication, client authentication as well as encrypted data transmission.

0037According to a further embodiment of the first aspect of the invention the first communication protocol comprises an application layer comprising the Hyper Text Transfer Protocol (HTTP).

0038This protocol is broadly applicable and widespread. In combination with a SSL or TLS protocol on the network layer the Hyper Text Transfer Protocol Secure (HTTPS) can preferably be established.

0039According to a further embodiment of this aspect of the invention the second communication comprises a network layer comprising the Transmission Control Protocol/Internet Protocol (TCP/IP) and an application layer comprising the Hyper Text Transfer Protocol (HTTP).

0040These protocols are broadly applicable and widespread. In the normal mode of operation a user of the client computer could browse the internet by means of the browser application using TCP/IP and HTTP.

0041According to a further embodiment of this aspect of the invention the method comprises the step of performing a user authentication by the server computer.

0042This additional authentication enhances the security of the method. Such a user authentication might be e.g. performed by means of a password or a personal identification number (PIN) of the user. As an example, the server can send a server response to the client computer in which the user is asked to enter his password or PIN. The password or PIN is stored at the server computer and can hence be checked by the server computer. A user authentication is understood as an authentication that cannot be automatically performed by the hardware device itself, but needs additional input of the user of the system. This prevents that an adversary can misuse a stolen hardware device without knowing the additional Password or PIN. On the contrary, the mutual authentication between the hardware device and the server computer that is performed during the first communication protocol can be performed automatically without further user interaction. The user authentication should preferably be performed before any predefined transaction information is sent from the secure hardware device to the server computer.

0043According to a further embodiment of this aspect of the invention the method comprises the step of performing a user authentication by the hardware device.

0044This additional authentication enhances the security of the method. Such a user authentication might be e.g. performed by means of a password or a personal identification number (PIN). As an example, the hardware device could display a message in which the user is asked to enter his password or PIN by means of the hardware device input unit. The password or PIN is stored in the hardware device or on a smartcard readable by the hardware device and can hence be checked by the hardware device. This prevents that an adversary can misuse a stolen hardware device without knowing the additional Password or PIN. Other user authentication methods like biometric authentication, e.g. fingerprint reading, can be used as well. In this embodiment the user authentication should preferably be performed before starting or establishing respectively the first communication protocol.

0045According to a second aspect of the invention there is provided a hardware device according to claim 2.

0046Such a hardware device can be implemented and used in a flexible and efficient way for improving the security of electronic transactions. In particular there may be no need to implement changes on the side of the server computers if the first communication protocol is known to the server, e.g. SSL. The hardware device can work together with common client computers such as desktop PCs or laptops. The coupling between the client computer and the hardware device may be implemented by connecting the hardware device interface unit to a first interface of the client computer. The hardware device interface unit may be a wireless or a wired interface unit. As an example, the hardware device interface unit may be a Universal Serial Bus (USB)-interface.

0047According to an embodiment of the invention the hardware device is adapted to cancel the electronic transaction if no user confirmation is received.

0048According to an embodiment of the second aspect of the invention the hardware device comprises a security token for storing security sensitive data.

0049Such a security token is a hardware unit, also denoted as hardware token, which can store security sensitive data, in particular security sensitive user data, in a tamper-resistant way. In other words, security sensitive data stored in the security token cannot be read out or manipulated. The degree or level of tamper resistance can be adapted to the security requirements of the respective application. The security token may be e.g. a hardware component comprising a smartcard chip that stores the security sensitive data.

0050According to an embodiment of the second aspect of the invention the hardware device comprises a smart card reader for reading security sensitive data from a smart card.

0051According to this embodiment the smartcard chip of the smartcard stores the security sensitive data. The smartcard can be kept by the user at a different place than the hardware device. Before running the hardware device, the user has to put the smart card into the smart card reader of the hardware device.

0052According to an embodiment of the second aspect of the invention the hardware device has one or more predefined levels of tamper- resistance.

0053The predefined levels of tamper resistance can be adapted to the security requirements of the respective application. The higher the security requirements of the application, the higher should the level of tamper resistance be chosen. Preferably, the level of tamper resistance is tamper proof.

0054The predefined levels of tamper resistance may address different attacks, e.g. a level of tamper resistance against malicious software or a level of tamper resistance against physical manipulation of the hardware or a level of tamper-resistance against inspection of the hardware device, in particular inspection of the storage or the memory, by means of a microscope. Malicious software, also denoted as malware, may be understood as any software that has the intention to harm, alter, or manipulate the correct function of the hardware device. Such malicious software may be e.g. a virus, a worm, a trojan horse, spyware or other unwanted software. In other words, malicious software is software that is designed to infiltrate, damage or harm a computer system.

0055According to an embodiment of the second aspect of the invention the predefined level of tamper-resistance of the hardware device is higher than the level of tamper-resistance of the client computer.

0056This means that it is more difficult for an adversary to manipulate or tamper the hardware device than to manipulate the client computer. Concentrating on the tamper resistance of the hardware device is more cost efficient than improving the tamper resistance of the whole client computer. In particular it is more difficult for an adversary to place malicious software on the hardware device than on the client computer.

0057According to an embodiment of the second aspect of the invention the hardware device is designed in such a way that no software applications can be loaded onto the hardware device.

0058This prevents that viruses, worms or other malicious software may manipulate or harm the functioning of the hardware device. This embodiment can be e.g. implemented by storing the program or programs of the hardware device in a fused memory. In other words, after having loaded the program or the programs in the program memory of the hardware device, the program memory is fused. This prevents that any further programs can be loaded and run on the hardware device.

0059According to an embodiment of the second aspect of the invention the security sensitive data comprises a private key and trust root information.

0060The private key will be used for performing the first communication protocol with the server computer, in particular the mutual authentication.

0061The trust root information defines which authorities the hardware device trusts. The trust root information may comprise e.g. one or more certificate authority root keys of certificate authorities that the hardware device trusts. This allows using Public Key Infrastructure (PKI)-technology for performing the mutual authentication of the first communication protocol.

0062According to an embodiment of the second aspect of the invention the hardware device comprises a hardware device input unit for confirming and/or canceling a transaction.

0063The hardware device input unit can be established e.g. by one or more buttons, e.g. by a confirm-button and/or a cancel-button.

0064According to a third aspect of the invention there is provided a method for controlling electronic transactions between a server computer and a client computer by means of a hardware device according to claim 12.

0065This aspect of the invention relates to a method according to which the server responses are parsed. The predefined transaction information of the server responses may e.g. be server challenges to the user or security sensitive information from the server computer to the user.

0066As an example, such a method could be used to perform a downloading of software with enhanced security. Before the hardware device forwards the software to the client computer, the hardware device may display a message in which the user is asked whether he agrees with the downloading. Furthermore, the server could send some user verifiable information with respect to the integrity of the software to the hardware device. Then the hardware device would display the user verifiable information on the hardware device display and the user could verify the integrity of the software before downloading it. This is in particular useful to avoid downloading of malicious software.

0067According to a fourth aspect of the invention there is provided a hardware device for controlling electronic transactions according to claim 13.

0068The fourth aspect of the invention addresses a hardware device in which the method of the third aspect of the invention may be performed.

0069The steps of the different aspects of the invention can be performed in different orders. Furthermore, the steps may also be combined, i.e. that e.g. two or more steps are performed together.

0070Any of the device features may be applied to the method aspect of the invention and vice versa. Advantages of the device features apply to corresponding method features and vice versa.

DESCRIPTION OF THE DRAWINGS

0071Preferred embodiments of the invention are described in detail below, by way of example only, with reference to the following schematic drawings.

0072The drawings are provided for illustrative purpose only and do not necessarily represent practical examples of the present invention to scale. In the figures, same reference signs are used to denote the same or like parts. <ul id="ul0004" list-style="none"><li><figref idref="f0001">Figure 1</figref> is a block diagram of a system according to an embodiment of the present invention;</li><li><figref idref="f0002">Figure 2</figref> is a block diagram of a hardware device according to an embodiment of the present invention;</li><li><figref idref="f0003">Figure 3</figref> is a block diagram of a hardware device according to another embodiment of the present invention;</li><li><figref idref="f0004">Figure 4</figref> illustrates the communication flow between a browser application, a proxy application, the hardware device and a server computer according to an embodiment of the present invention;</li><li><figref idref="f0005">Figure 5</figref> shows a schematic illustration of a message flow of a method according to an embodiment of the invention in a normal mode of operation;</li><li><figref idref="f0006 f0007 f0008">Figure 6 to Fig. 8</figref> show schematic illustrations of message flows of a method according to an embodiment of the invention in a secure mode of operation.</li></ul>

0073<figref idref="f0001">Figure 1</figref> shows a system 100 according to an embodiment of the present invention. The system 100 comprises a server computer 110, a client computer 120 and a hardware device 130. The client computer 120 comprises a client computer display 121 and a client computer input unit 122. The client computer input unit 122 comprises a keyboard 123 and a mouse 124. The client computer 120 furthermore comprises a processing unit 150, memory 151 (e.g., a volatile memory device) and storage 152 coupled by means of a bus system 153 and arranged in a computer case 154. The storage 152 may include a non-volatile memory device (e.g., EEPROM, ROM, PROM, RAM, DRAM, SRAM, flash, firmware, programmable logic, etc.), magnetic disk drive, optical disk drive, tape drive, etc. The storage 152 may comprise an internal storage device, an attached storage device and/or a network accessible storage device. The client computer 120 may include a program logic 157 including program code 158 that may be loaded into the memory 151 and executed by the processing unit 150. In certain embodiments, the program logic 157 including the program code 158 may be stored in the storage 152. Therefore, while <figref idref="f0001">Fig. 1</figref> shows the program logic 157 separately from the other elements, the program logic 157 may be implemented in the storage 152.

0074The client computer 120 is coupled to a communication network 160 via a first interface 156. The first interface 156 may be a wireless or a wired interface, in particular an Universal Serial Bus (USB)-interface. The communication network 160 may be the Internet. The client computer 120 is coupled to the hardware device 130 via a second interface 155. The second interface 155 may be a wireless or a wired interface, in particular an USB-interface. The client computer 120 may be a Personal Computer (PC). The server computer 110 is coupled to the communication network 160 as well. The server computer 110 can e.g. be the server computer of a bank, an insurance company or an entity that offers electronic transactions via the communication network 160, in particular the Internet.

0075<figref idref="f0002">Figure 2</figref> shows an embodiment of the hardware device 130 of <figref idref="f0001">Fig. 1</figref> in more detail. The hardware device 130 comprises a processing unit 200, a hardware device display 210, memory 220 (e.g., a volatile memory device) and storage 230. The storage 230 may include a non-volatile memory device (e.g., EEPROM, ROM, PROM, RAM, DRAM, SRAM, flash, firmware, programmable logic, etc.). The hardware device 130 may include a program logic 240 including program code 241 that may be loaded into the memory 220 and executed by the processing unit 200. In certain embodiments, the program logic 240 including the program code 241 may be stored in the storage 230. Therefore, while <figref idref="f0002">Fig. 2</figref> shows the program logic 240 separately from the other elements, the program logic 240 may be implemented in the storage 230. The hardware device 130 furthermore comprises a smart card reader 250, a hardware device interface unit 270, also denoted as I/O-unit 270, and a hardware device input unit 280. The hardware device interface unit 270 may be a wireless or wired interface, in particular a Universal Serial Bus (USB)-interface. The hardware device interface unit 270 may be used to connect or couple the hardware device 130 to the client computer 120. The hardware device input unit 280 is provided for user input and may comprise one or more buttons or a complete keyboard. As an example, the hardware device input unit 280 could consist of only two buttons, one cancel-button for canceling a transaction and one confirm-button for confirming a transaction. The hardware device 130 is covered by a housing 290, e.g. by a plastic housing.

0076The smart card reader 250 can read from a smart card 260 security sensitive data, in particular security sensitive user data, such as a private key and trust root information.

0077<figref idref="f0003">Figure 3</figref> shows another embodiment of the hardware device 130 of <figref idref="f0001">Fig. 1</figref> in more detail. The hardware device 130 according to the embodiment of <figref idref="f0003">Fig. 3</figref> comprises the processing unit 200, the hardware device display 210, the memory 220, the storage 230, the program logic 240 including the program code 241, the hardware device interface unit 270, the hardware device input unit 280 and the housing 290 as described with reference to <figref idref="f0002">Fig. 2</figref>.

0078Furthermore, it comprises a built-in security token 310 for storing security sensitive data such as a private key and trust root information. The security token 310 may be e.g a smart card chip.

0079The hardware device 130 is preferably initialized in a trusted and secure environment, e.g. on a secure site of a bank. Such an initialization comprises e.g. the loading of the security sensitive information on the security token 310 or on the smart card 260.

0080The hardware device 130 may be e.g. implemented as an USB-stick.

0081<figref idref="f0004">Fig. 4</figref> illustrates the communication flow between a browser application 410 running on the client computer 120, a proxy application 420 running on the client computer 120, the hardware device 130, the communication network 160 and the server computer 110.

0082According to an embodiment of the invention the browser application 410 and the proxy application 420 are implemented as program code 158 of the program logic 157 of the client computer 120 as described with reference to <figref idref="f0001">Fig. 1</figref>. The browser application 420 may be in particular a web browser that enables a user to display and interact with text, images, videos, music and other information that may be located on a web page or website of the Internet. In particular, the browser application 420 enables a user to display and interact with text, images, videos, music and other information that is accessible via the communication network 160 from the server computer 110. The browser application 410 may communicate with the server computer 110 via the proxy application 420 and via the communication network 160 e.g. by means of the HTTP-protocol in the application layer and the Transmission Control Protocol/Internet Protocol (TCP/IP) in the network layer.

0083In a normal mode of operation the browser application 410 connects via the proxy application 420 to the communication network 160. In the normal mode of operation the browser application 410 runs a second communication protocol and can send client requests, e.g. HTTP get requests, via the proxy application 420 and the communication network 160 to the server computer 110. In the other direction, the server computer 110 can send in the normal mode of operation server responses, e.g. HTTP-responses, via the communication network 160 and the proxy application 420 to the browser application 410. In the normal mode of operation the proxy application 420 works as forwarder between the browser application 410 and the communication network 160, while concurrently observing and parsing respectively the client requests for a predefined set of client requests. The predefined set of client requests may be e.g. a set of Uniform Resource Locators (URLs). The predefined set of client requests represent a set of resources for which the user of the client computer 120 has predefined that a communication with this resource should be controlled by the hardware device 130. As an example, the user of the client computer 120 could define the URL of his bank as a predefined request in the proxy application 420. Then the proxy application 420 would observe whether the user enters the corresponding URL of this bank in the browser application 410. In other words, the proxy application 420 observes whether the user sends a client request to access the predefined URL via the communication network 160 to the server computer 110. Upon detection of one of the predefined client requests the proxy application 420 switches to and initiates a secure mode of operation. In the secure mode of operation the proxy application 420 changes the data flow and routes client requests received from the browser application 410 to the hardware device 130. Furthermore, the proxy application 420 initiates the secure mode of operation by sending an appropriate signal, e.g. a secure mode enable signal, to the hardware device 130. Then the hardware device 130 initiates and runs a first communication protocol with encrypted data transmission and mutual authentication between the server computer 110 and the hardware device 130. In the following the hardware device 130 works as an intelligent interface between the server computer 110 and the browser application 410 of the client computer 120. In other words, the hardware device 130 controls and observes the data communication between the server computer 110 and the browser application 410. In the secure mode of operation the proxy application 420 operates as a kind of switch. On the one hand the proxy application 420 forwards in the secure mode of operation client requests received from the hardware device 130 to the communication network 160 and server responses received from the communication network 160 to the hardware device 130. On the other hand the proxy application 420 forwards in the secure mode of operation client requests received from the browser application 410 to the hardware device 130 and server responses received from the hardware device 130 to the browser application 410.

0084After the first communication protocol has been established, the hardware device 130 parses client requests received from the client computer 120 or from the browser application 410 respectively for predefined transaction information. In other words, the hardware device 130 observes whether the data traffic it receives from the client computer 120 contains any predefined transaction information. Such predefined transaction information may be e.g. security sensitive information such as payment details, payment amounts etc. The predefined transaction information may be e.g. predefined by the owner of the respective URL, e.g. by the bank that the user wants to perform a transaction with. The predefined transaction information may be e.g. sent by means of a HTTP post request. Upon detection of predefined transaction information the hardware device 130 interrupts the corresponding client request and displays the detected predefined transaction information on the hardware device display 210 of the hardware device 130. The user that wants to perform the transaction can then check on the hardware device display 210 whether the respective transaction information is correct. As an example, if the predefined transaction information relates to the transfer amount of an electronic payment, the hardware device 130 would display on the hardware device display 210 the respective transfer amount. The user can check on the hardware device display 210 if the transfer amount is correct. The hardware device 130 does only continue with the transaction if the user confirms the transaction via the hardware device input unit 280, e.g. by pressing a confirmation button. If the hardware device 130 receives such a confirmation, it continues with the transaction and forwards the transaction information via the proxy application 420 and the communication network 160 to the server computer 110. If the hardware device 130 receives no confirmation or a cancellation signal, it cancels the transaction and does not forward the transaction information to the proxy application 420.

0085Preferably, the hardware device 130 sends, upon detection of predefined transaction information, an interruption message, also denoted as confirmation request message, back to the browser application 410. Such an interruption message may indicate to the browser application 410 that the hardware device 130 has identified predefined transaction information and is waiting for a user confirmation before continuing with the transaction. The browser application 410 preferably displays a corresponding interruption message, also denoted as confirmation request message, to the user on the client computer display 121. Such an interruption message could e.g. inform the user that he should double-check on the hardware device display 210 whether the transaction information is correct and that he should confirm this via the hardware device input unit 280.

0086The hardware device 130 comprises a parsing program for parsing the client requests. The parsing program comprises the predefined transaction information and can be application-specific. As an example, banks could issue a bank-specific hardware device 130 on which a bank-specific parsing program is loaded. The respective bank could adapt the parsing program to its specific online banking process and its specific security needs and requirements. Preferably the parsing program is initialized in a trusted and secure environment, e.g. on a secure site of the bank. The parsing program is preferably loaded and stored in the security token 310 or the smart card 260 of the hardware device 130. However, according to another embodiment of the invention the parsing program could be stored in the storage 230 of the hardware device 130.

0087According to an embodiment of the invention the hardware device 130 parses server responses received from the server computer 110 for predefined transaction information. In other words, in addition to parsing the client request, the hardware device 130 parses also the server responses for predefined transaction information.

0088The parsing process performed by the hardware device 130 for client requests and server responses is indicated in <figref idref="f0004">Fig. 4</figref> by means of the dotted lines.

0089<figref idref="f0005">Figure 5</figref>, <figref idref="f0006">6</figref>, <figref idref="f0007">7</figref> and <figref idref="f0008">8</figref> show a schematic illustration of a message flow of a method according to an embodiment of the invention. Therein, the message flow between the server computer 110, the proxy application 420, the browser application 410 and the hardware device 130 is depicted with labeled arrows to which respective reference numbers are assigned. Further steps or sub-steps are indicated by reference numbers in a circle. The flow is understood as being performed sequentially from top to bottom as indicated by the increasing reference numbers.

0090<figref idref="f0005">Fig. 5</figref> illustrates the message flow in a normal mode of operation.

0091In a step 510 the user of the client computer 120 enters a client request, e.g. a URL of a website, by means of the client computer input unit 122. In a step 520 the browser application 410 sends the client request, e.g. a HTTP get request comprising the URL of a website, to the proxy application 420. In a step 530 the proxy application 420 parses the client request for a predefined set of requests, e.g. for a predefined set of URLs. In this example it is assumed that the client request sent in step 520 does not belong or correspond to the predefined set of client requests. Accordingly, the proxy application 420 forwards the client request in step 540 via the communication network 160 to the server computer 110. In step 550 the server computer 110 answers by sending back a server response, e.g. a HTTP-server response comprising an HTML-file of the requested URL. Then in step 560 the server response, e.g. the HTML-file of the requested URL, is displayed on the client computer display 121.

0092Steps 510, 520, 530, 540, 550 and 560 represent a normal mode of operation of the browser application 410 and the proxy application 420. The normal mode of operation can be performed without the hardware device 130. In the normal mode of operation a second communication protocol is run between the browser application 410 and the server computer 110.

0093In a step 570 the user of the client computer 120 enters another client request, e.g. a URL of a website, by means of the client computer input unit 122. In step 580 the browser application 410 sends a corresponding client request to the proxy application 420. In this example it is assumed that the client request sent in step 580 belongs or corresponds to the predefined set of client requests. As an example, the client request sent in step 580 might be a HTTP get request for a URL that belongs to the predefined set of URLs. This might be e.g. the URL of the website of the bank of the user. In a step 590 the proxy application 420 parses the client request for the predefined set of requests and detects that the client request sent in step 580 belongs or corresponds to the predefined set of client requests. Accordingly, the proxy application 420 switches to a secure mode of operation and initiates in step 595 the secure mode of operation in the hardware device 130 by sending a secure mode enable signal to the hardware device 130. The secure mode enable signal could be e.g. implemented as "initiate secure mode" - command that is understood by the hardware device 130. The secure mode enable signal indicates to the hardware device 130 that it shall start the secure mode of operation for the subsequent communication between the browser application 410 and the server computer 110.

0094With reference to <figref idref="f0006">Fig. 6</figref>, <figref idref="f0007">7</figref> and <figref idref="f0008">8</figref> the message flow in the secure mode of operation is illustrated.

0095After having received the secure mode enable signal in step 595, the hardware device 130 sends in step 605 a confirmation request message (CRM) via the proxy application 420 to the browser application 410. Then in step 610 the browser application 410 displays the confirmation request message to the user on the client computer display 121. The confirmation request message asks the user to confirm that the secure mode of operation shall be performed. It could e.g. read as follows: "The website you requested requires the initialization of a secure mode of operation. Please confirm that you agree by means of pressing the confirm button of your hardware device". In step 615 a corresponding message, in particular in a shortened form such as "Confirm secure mode?" is displayed on the hardware device display 210 of the hardware device 130. The confirmation response of the user can be received in step 620 via the hardware device input unit 280.

0096Upon confirmation of the user in step 620 the hardware device 130 sends in step 625 a hello message via the proxy application 420 and the communication network 160 to the server computer 110. In step 630 the server computer 110 sends a hello message back via the communication network 160 and the proxy application 420 to the hardware device 130. In step 635 the server computer 110 authenticates itself to the hardware device 130. This may include sending a server certificate (public key certificate) to the hardware device 130. Furthermore, it may include a certificate request for a client certificate. In step 640 the client computer 120 authenticates itself to the server computer 110. This may include sending a client certificate (public key certificate) to the server computer 110. In summary, the server computer 110 and the hardware device 130 perform in the steps 635 and 640 a mutual authentication.

0097In steps 645 and 650 the server computer 110 and the hardware device 130 exchange a symmetric cryptographic key SK, also denoted as session key.

0098Steps 625 - 650 may be e.g. implemented by means of the SSL/TLS handshake protocol.

0099In the following the data transmission between the hardware device 130 and the server computer 110 is performed in an encrypted way by means of the session key SK. This can be e.g. implemented by means of the SSL/TLS record protocol.

0100In step 655 the server computer 110 sends a user authentication response to the hardware device 130. Such a user authentication response could e.g. comprise a HTML-form with a user field and a password field in which the user shall enter his name and his password. The user authentication response is decrypted in step 657 by the hardware device 130 and then forwarded in a step 660 via the proxy application 420 to the browser application 410. In step 662 the user authentication response is displayed on the client computer display 121. In step 665 the user enters his personal authentication data, e.g. his user name and his password, into the corresponding HTML-form by means of the client computer input unit 122. Then in step 670 the browser application 410 sends a HTTP post request comprising the authentication data of the user to the hardware device 130. In step 675 the hardware device parses the HTTP post request for predefined transaction information. In this example it is assumed that a HTTP post request comprising information for user authentication is not predefined transaction information. Accordingly in step 677 the HTTP post request is encrypted by means of the symmetric session key SK and send in step 680 to the server computer 110. The server computer 110 decrypts the HTTP post request by means of the symmetric session key SK and, if the user authentication data is valid, authenticates the user in step 695. Otherwise the server computer 110 may cancel the transaction.

0101Steps 655 to 695 illustrate an additional user authentication by the server computer 110 which may be implemented to enhance the security in case that the hardware device 130 is stolen or lost. According to another exemplary embodiment the additional user authentication described with reference to steps 655 to 695 is replaced by a user authentication performed by the hardware device 130.

0102The illustration of the message flow in the secure mode of operation after the user authentication is continued with reference to <figref idref="f0007">Fig. 7</figref>.

0103In step 705 the server computer 110 sends as server response a transaction response via the proxy application 420 to the hardware device 130. Such a transaction response could e.g. comprise an HTML-file with bank account data of the user that has been authenticated in the previous steps. In a step 710 the hardware device 130 decrypts the server response by means of the symmetric session key SK. In step 715 the hardware device 130 may parse the server response for predefined transaction information. In this example it is assumed that server response received in step 705 does not comprise predefined transaction information. Then in step 720 the decrypted server response is sent from the hardware device 130 via the proxy application 420 to the browser application 410. In step 725 the browser application 410 displays the server response on the client computer display 121 of the client computer 120.

0104According to another example as illustrated with dotted lines it is assumed that the server response received in step 705 does comprise predefined transaction information. Then the hardware device 130 detects in the parsing step 715 that the server response comprises predefined transaction information. Accordingly, the hardware device 130 displays in step 717 the predefined transaction information of the server response on the hardware device display 210. If the user confirms in a step 718 the transaction information of the server response displayed on the hardware device display 210 by means of the hardware device input unit 280, the method is continued with step 720. If the user does not confirm the transaction information of the server response, the hardware device 130 cancels the transaction.

0105In step 730 the user enters a client request that does not comprise predefined transaction information. This could be e.g. a client request to get specific data of the bank account of the user, to show more details of the bank account or to perform an initial check of a planned electronic transaction, e.g. of a money transfer. In step 735 the browser application 410 sends the client request via the proxy application 420 to the hardware device 130. In step 740 the hardware device 130 parses the received client request for predefined transaction information and detects that the client request does not comprise predefined transaction information. Then in step 745 the hardware device 130 encrypts the client request by means of the symmetric session key SK and sends the encrypted client request in step 750 to the proxy application 420. The proxy application 420 forwards the encrypted client request in the step 750 via the communication network 160 to the server computer 110. In step 755, the server computer 110 decrypts the received encrypted client request by means of the symmetric session key SK and processes the decrypted client request.

0106In step 760 the server computer 110 sends a server response with respect to the received client request via the proxy application 420 back to the hardware device 130. In a step 765 the hardware device 130 decrypts the server response by means of the symmetric session key SK. In step 770 the hardware device 130 may parse the server response for predefined transaction information. In this example it is assumed that server response received in step 760 does not comprise predefined transaction information. Accordingly, in step 775 the decrypted server response is sent from the hardware device 130 via the proxy application 420 to the browser application 410 and in step 780 the browser application 410 displays the server response on the client computer display 121 of the client computer 120.

0107<figref idref="f0008">Fig. 8</figref> illustrates the message flow in the secure mode of operation for a client request that comprises predefined transaction information.

0108In step 805 the user enters a client request that does comprise predefined transaction information. The predefined transaction information may be e.g. a final order to perform an electronic transaction. Such a final order may be e.g. a money transfer order with payment details such as the amount of the money transfer. The predefined transaction information may be e.g. entered by the user in a corresponding HTML-form by means of the client computer input unit 122. In step 810 the browser application 410 sends a client request comprising the predefined transaction information via the proxy application 420 to the hardware device 130. This could be e.g. a HTTP-post request. In step 815 the hardware device 130 parses the received client request for predefined transaction information and detects that the client request comprises predefined transaction information, e.g. the above mentioned final payment details of a money transfer. Then in step 820 the hardware device 130 sends a confirmation request message (CRM) via the proxy application 420 to the browser application 410. The browser application 410 displays in step 825 the confirmation request message on the client computer display 121 of the client computer 120. The confirmation request message indicates to the user that the hardware device 130 has detected predefined transaction information and that the user should check and confirm the correctness of the transaction information on the hardware device display 210 of the hardware device 130. The confirmation request message could e.g. read as follows: "Please check the transfer amount on the display of your security token. If the transfer amount is correct, confirm the transaction by pressing the confirm button of the security token".

0109In step 830 the hardware device 130 displays on the hardware device display 210 the predefined transaction information (PTI), e.g. the amount of money to be transferred and the destination account. In addition some confirmation message could be displayed on the hardware device display 210 as well. As the hardware device display 210 might be rather small, such a confirmation message is preferably rather short like "Please confirm transfer of amount X to account Y". The user can then check on the hardware device display 210 whether the transaction information is correct. Furthermore, he can compare the transaction information displayed on the hardware device display 210 with the transaction information displayed on the client computer display 121. If the user confirms in a confirmation step 835 that the transaction information displayed on the hardware device display 210 is correct, e.g. by pressing a confirmation button of the hardware device input unit 280, the transaction will be continued. Then in step 840 the hardware device 130 encrypts the client request comprising the transaction information by means of the symmetric session key SK and sends the encrypted client request in step 845 to the proxy application 420. The proxy application 420 forwards the encrypted client request via the communication network 160 to the server computer 110. The server computer 110 decrypts in step 850 the received encrypted client request by the symmetric session key SK. Then in step 855 the server computer 110 performs the transaction. In the example of money transfer the server computer 110 would transfer in step 855 the money to the destination account.

0110If the user does not confirm that the transaction information displayed on the hardware device display 210 is correct, the method is continued with step 870. This is indicated by the dotted line. The non-confirmation of the transaction may be invoked actively by the user, e.g. by pressing a cancel-button of the hardware device input unit 280 or passively, e.g. if the hardware device 130 does not receive a confirmation within a predefined timeout period. Then in step 875 the hardware device 130 cancels the transaction and does not forward the transaction information to the server computer 110. Furthermore, in step 880 the hardware device 130 might send a cancellation message (CM) via the proxy application 420 to the browser application 410. The browser application 410 displays in step 885 the cancellation message on the client computer display 121 of the client computer 120. The cancellation message indicates to the user that the hardware device 130 has cancelled the transaction. The cancellation message could e.g. read as follows: "The transaction has been cancelled due to non-confirmation. If you have observed a discrepancy between the transaction information you entered via the keyboard of your PC and the transaction information displayed on the display of your security token, your PC might be compromised by malicious software". In addition, the cancellation message could be displayed in step 890 on the hardware device display 210 as well.

0111Any disclosed embodiment may be combined with one or several of the other embodiments shown and/or described. This is also possible for one or more features of the embodiments.

Additional Embodiment Details

0112The described techniques may be implemented as a method, apparatus or article of manufacture involving software, firmware, micro-code, hardware and/or any combination thereof. The term "article of manufacture" as used herein refers to code or logic implemented in a medium, where such medium may comprise hardware logic [e.g., an integrated circuit chip, Programmable Gate Array (PGA), Application Specific Integrated Circuit (ASIC), etc.] or a computer readable medium, such as magnetic storage medium (e.g., hard disk drives, floppy disks, tape, etc.), optical storage (CD-ROMs, optical disks, etc.), volatile and non-volatile memory devices [e.g., Electrically Erasable Programmable Read Only Memory (EEPROM), Read Only Memory (ROM), Programmable Read Only Memory (PROM), Random Access Memory (RAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), flash, firmware, programmable logic, etc.]. Code in the computer readable medium is accessed and executed by a processor. The medium in which the code or logic is encoded may also comprise transmission signals propagating through space or a transmission media, such as an optical fiber, copper wire, etc. The transmission signal in which the code or logic is encoded may further comprise a wireless signal, satellite transmission, radio waves, infrared signals, Bluetooth, etc. The transmission signal in which the code or logic is encoded is capable of being transmitted by a transmitting station and received by a receiving station, where the code or logic encoded in the transmission signal may be decoded and stored in hardware or a computer readable medium at the receiving and transmitting stations or devices. Additionally, the "article of manufacture" may comprise a combination of hardware and software components in which the code is embodied, processed, and executed. Of course, those skilled in the art will recognize that many modifications may be made without departing from the scope of embodiments, and that the article of manufacture may comprise any information bearing medium. For example, the article of manufacture comprises a storage medium having stored therein instructions that when executed by a machine results in operations being performed. Certain embodiments can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc. Furthermore, certain embodiments can take the form of a computer program product accessible from a computer usable or computer readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk - read only memory (CD-ROM), compact disk - read/write (CD-R/W) and DVD. The terms "certain embodiments", "an embodiment", "embodiment", "embodiments", "the embodiment", "the embodiments", "one or more embodiments", "some embodiments", and "one embodiment" mean one or more (but not all) embodiments unless expressly specified otherwise. The terms "including", "comprising", "having" and variations thereof mean "including but not limited to", unless expressly specified otherwise. The enumerated listing of items does not imply that any or all of the items are mutually exclusive, unless expressly specified otherwise. The terms "a", "an" and "the" mean "one or more", unless expressly specified otherwise. Devices that are in communication with each other need not be in continuous communication with each other, unless expressly specified otherwise. In addition, devices that are in communication with each other may communicate directly or indirectly through one or more intermediaries. Additionally, a description of an embodiment with several components in communication with each other does not imply that all such components are required. On the contrary a variety of optional components are described to illustrate the wide variety of possible embodiments. Further, although process steps, method steps, algorithms or the like may be described in a sequential order, such processes, methods and algorithms may be configured to work in alternate orders. In other words, any sequence or order of steps that may be described does not necessarily indicate a requirement that the steps be performed in that order. The steps of processes described herein may be performed in any order practical. Further, some steps may be performed simultaneously, in parallel, or concurrently. When a single device or article is described herein, it will be apparent that more than one device/article (whether or not they cooperate) may be used in place of a single device/article. Similarly, where more than one device or article is described herein (whether or not they cooperate), it will be apparent that a single device/article may be used in place of the more than one device or article. The functionality and/or the features of a device may be alternatively embodied by one or more other devices which are not explicitly described as having such functionality/features. Thus, other embodiments need not include the device itself.

0113Computer program means or computer program in the present context mean any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following a) conversion to another language, code or notation; b) reproduction in a different material form.