WO2010009516A1 - Système et processus de communications sécurisées - Google Patents

Système et processus de communications sécurisées Download PDF

Info

Publication number
WO2010009516A1
WO2010009516A1 PCT/AU2009/000951 AU2009000951W WO2010009516A1 WO 2010009516 A1 WO2010009516 A1 WO 2010009516A1 AU 2009000951 W AU2009000951 W AU 2009000951W WO 2010009516 A1 WO2010009516 A1 WO 2010009516A1
Authority
WO
WIPO (PCT)
Prior art keywords
computer system
server
secure
user interface
graphical user
Prior art date
Application number
PCT/AU2009/000951
Other languages
English (en)
Inventor
Ian James Millsom
Original Assignee
Brown Leaf Pty Ltd As Trustee For The Brown Leaf Trust
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Brown Leaf Pty Ltd As Trustee For The Brown Leaf Trust filed Critical Brown Leaf Pty Ltd As Trustee For The Brown Leaf Trust
Publication of WO2010009516A1 publication Critical patent/WO2010009516A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/552—Detecting local intrusion or implementing counter-measures involving long-term monitoring or reporting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2151—Time stamp

Definitions

  • the present invention relates to a system and process for secure communication, and in particular over an open communications network such as the Internet.
  • GUI graphical user interface
  • a system for secure communications including: a server; and a secure graphical user interface (GUI) engine for execution by a computer system executing an operating system, the secure GUI engine being configured to:
  • the secure GUI engine may be configured to store the user data in encrypted form and only in volatile random access memory of the first computer system prior to sending said user data to said remote server.
  • the secure GUI engine may be configured to overwrite the volatile random access memory storing the user data once the user data has been sent to said remote server.
  • the secure GUI engine may be configured to store GUI data representing the graphical user interface components in encrypted form and only in volatile random access memory of the first computer system.
  • the secure GUI engine may be configured to overwrite the volatile random access memory storing the GUI data once the graphical user interface components are no longer required to be displayed.
  • the secure GUI engine may be configured to receive from the server programming instructions to process user interaction with one or more of the graphical user interface components.
  • the programming instructions may be in the form of one or more scripts and/or libraries.
  • the secure GUI engine may be configured to store the one or more scripts and/or libraries at random locations of random access memory of the computer system to hide the scripts and/or libraries from other processes of the computer system.
  • the secure connections may be based on one or more asymmetric blocks ciphers.
  • the secure GUI engine may be configured to generate a pair of public and private encryption keys for each session, and to send the secure GUI engine's public key to the server in a message encrypted with the server's public encryption key.
  • the secure GUI engine may be configured to determine identification information at least nominally unique to the computer system and representing an identity of the computer system, and to send the identification information to the server; and wherein the server is configured to receive the identification information and to compare it to previously stored identification information associated with a plurality of computer systems, and to allow a - A -
  • the identification information may be associated with a plurality of hardware components of the computer system.
  • the server may be configured to determine a WAN IP address associated with the secure GUI engine from an IP packet header received from the secure GUI engine, to generate a first hash value from the WAN IP address and the identification information, and to send the determined WAN IP address and the first hash value in a message to the secure GUI engine, the secure GUI engine may be configured to receive the message containing the WAN IP address and the first hash value and to generate a second hash value from at least the received WAN IP address and the identification information and to compare the first and second hash values to determine whether the WAN IP address in the message was modified during transit.
  • the secure GUI engine may be configured to generate a random session key and to send the secure GUI engine's random session key and the identification information to the server in a message encrypted with the server's public encryption key.
  • the secure GUI engine may be configured to generate a new pair of encryption keys for each user session, and to send a public encryption key of the pair of encryption keys to the server in the encrypted message, the server may be configured to encrypt messages sent to the secure GUI engine with the secure GUI engine's public encryption key so that said messages can only be decrypted by the secure GUI engine.
  • the secure GUI engine may be configured to generate a respective timestamp for sending with each message sent to the server, and the server may be configured to compare timestamps received from the secure GUI engine to assess whether the timestamps are consistent with a single user session, and to allow a user session to be established only if the timestamps are consistent with a single user session.
  • the server may be configured to store association data representing associations between computer systems and users of the computer systems, and to allow a session to be established with a user using one of the computer systems only if that user and that computer system are both authenticated by the server and in mutual association.
  • the server may be configured to validate the identity of a computer system and to generate a first hash value from the WAN and LAN IP addresses of the computer system and the identification information of the computer system.
  • the server may be an authentication server and the system may further include one or more login servers, the authentication server may be configured to generate a message containing session information for a selected one of the one or more login servers, and to encrypt the message using a public encryption key of the selected login server and to encrypt the encrypted message using a public encryption key of the computer system, and to send the doubly-encrypted message to the computer system; and the computer system may be configured to receive the doubly-encrypted message, decrypt the doubly-encrypted message using the computer system's private key and to send the resulting encrypted message to the selected login server; the selected login server may be configured to decrypt the encrypted message using its private key to determine the session information and to forward the session information to the authentication server for verification.
  • the selected login server may be configured to send at least part of the session information to the authentication server in a message encrypted using the authentication server's public encryption key
  • the authentication server may be configured to decrypt the message to determine the at least part of the session information and thereby to verify the received session information and determine an identifier for the user corresponding to the selected login server, and to send the identifier to the login server for determining corresponding authentication information for the user.
  • GUI secure graphical user interface
  • the present invention also provides a secure communications process for execution by a computer system executing an operating system, the secure communications process including:
  • the present invention also provides at least one computer-readable storage medium having stored thereon programming instructions configured to cause a computer system executing an operating system to execute a process for secure communications, including:
  • the present invention also provides a system for secure communications, including: a client computer program for execution on a client computer system; and a server computer system; wherein the client computer program is configured to draw shapes on a display of the client computer system based on GUI data received into volatile random access memory of the client computer system from the server computer system during an interactive user session, the shapes appearing to be graphical user interface components to a user of the client computer system, and not being based on objects provided by an operating system, windowing system, or library associated with the client computer system so that the drawn shapes constitute virtual graphical user interface components hidden from other processes of the computer system, the client computer program being configured to receive and process user interaction events to determine whether the user interaction events are associated with any of the virtual graphical user interface components, and, if so, to redraw one or more of the virtual graphical user interface components so that the virtual graphical user interface components appear to respond to user interaction, window state data representing the graphical user interface components being stored only in volatile random access memory of the client computer system and only during the user session.
  • the client computer program stores the window state data in the volatile random access memory of the computer system in encrypted form.
  • the server computer system is configured to send, to the client computer program, programming instructions to handle user interaction with the virtual graphical user interface components.
  • the programming instructions are in the form of one or more scripts or libraries.
  • scripts or libraries received from the server computer system are randomly distributed in random access memory of the client computer system under control of the client computer program to hide the scripts or libraries from other processes of the client computer system.
  • the present invention also provides a system for secure communications, including: a client computer program for execution on a client computer system; and a server computer system; wherein: the client computer program is configured to collect identification information associated with a plurality of hardware components of the client computer system, the identification information being at least nominally unique to the client computer system and thereby representing an identity of the computer system, and to send the collected information to the server computer system; and the server computer system is configured to receive the identification information and to compare it to previously stored information associated with hardware components of client computer systems, and to establish a user session with the client computer program only if the comparison indicates that the client computer program is known to the server computer system.
  • the client computer program is configured to draw shapes and text on a display of the client computer system based on shape data received from the server computer system, the shapes and text appearing to be graphical user interface objects to a user of the client computer system, and being drawn by the client computer program to hide the graphical user interface objects from other processes executing on the client computer system.
  • the shapes and text appear to be at least one window.
  • the shapes and text appear to be at least one window having one or more interactive controls.
  • the shapes and text appear to be at least one window having one or more user input fields.
  • the shapes and text appear to be at least one window having one or more text boxes to receive user input.
  • the client computer program is configured to maintain, in volatile memory of the client computer system, display data representing the shapes and text drawn on the display, and to encrypt the display data stored in the volatile memory to hide the display data from other processes executing on the client computer system.
  • the client computer program is configured to associate user interaction events with at least one of the shapes drawn on the display and to redraw the at least one shape to give the appearance of a graphical user interface object responding to said user interaction events.
  • the client computer program is configured to associate keyboard events with at least one of the shapes appearing to be a text box, and to draw corresponding text within said shape to give the appearance of a text box responding to said keyboard events.
  • the client computer program is configured to receive executable code from the server computer system, the executable code being configured to handle user interaction with the shapes drawn on the display.
  • the client computer program is configured to process user interaction events to determine user input data provided by a user of the client computer system, and to send the user input data to the server computer system for processing.
  • the client computer program is configured to receive executable code from the server computer system, the executable code being configured to associate user interaction events with at least one of the shapes drawn on the display and to redraw the at least one shape to give the appearance of a graphical user interface object responding to said user interaction events.
  • the executable code is in the form of at least one dynamic link library (DLL) or script.
  • DLL dynamic link library
  • the shape data received from the server computer system includes login window data defining shapes and text that, when drawn on the display of the client computer system by the client computer program, appear to be a login window to a user of the client computer program, the login window including user authentication fields for entering user authentication data, the client computer program being configured to send the user authentication data to the server computer system, the server computer system being configured to compare the user authentication data with previously stored user authentication data, and to establish a user session with the client computer program only if the user is authenticated by the server computer system.
  • login window data defining shapes and text that, when drawn on the display of the client computer system by the client computer program, appear to be a login window to a user of the client computer program, the login window including user authentication fields for entering user authentication data
  • the client computer program being configured to send the user authentication data to the server computer system
  • the server computer system being configured to compare the user authentication data with previously stored user authentication data, and to establish a user session with the client computer program only if the user is authenticated by the server computer system.
  • the server computer system is configured to maintain associations between client computer systems and users of the client computer systems, and to establish a user session with the client computer program only if the user is authenticated and is associated with the client computer system.
  • the present invention also provides a process for secure communications, the process being executed by a first computer system, and including: receiving, from a second computer system, window data representing graphical user interface objects; and displaying the graphical user interface objects on a display of the first computer system, state data representing the graphical user interface objects being stored only in volatile memory of the first computer system and hidden from other processes executing on the first computer system.
  • the window data is in a form known only to the process.
  • the window data is in a non-standard form known only to the process.
  • the window data represents coordinates of each of a plurality of shapes to be displayed, each shape corresponding to a graphical user interface component.
  • the state data is stored in encrypted form in the volatile memory of the first computer system.
  • the present invention also provides a computer-readable storage medium having stored thereon a client application for execution on a computer system, the client application including programming instructions configured to perform the steps of: receiving, from a server, window data representing graphical user interface objects; displaying the graphical user interface objects on a display of the computer system, state data representing the graphical user interface objects being stored only in volatile memory of the computer system and hidden from users of the computer system and other applications executing on the computer system; and responding to user interaction with the graphical user interface objects by adjusting the display of the graphical user interface objects accordingly.
  • the present invention also provides a process for secure communications, the process being executed by a computer system, and including:
  • the present invention also provides a process for secure communications, the process being executed by a first computer system, and including: (i) at a first time:
  • the second plurality of identification information items is a subset of the first plurality of identification information items.
  • the second plurality of identification information items is a randomly selected subset of the first plurality of identification information items.
  • the second plurality of identification information items is randomly selected at the second time.
  • the identification information items are encrypted using a public key of the second computer system prior to being sent to the second computer system.
  • the encrypted identification information items are sent to the second computer system using secure sockets layer (SSL) encryption.
  • SSL secure sockets layer
  • the process includes: receiving validation data representing successful validation of the identity of the first computer system, the validation data including a WAN address of the first computer system and a first hash value generated from the WAN address and the second plurality of identification information items; generating a second hash value from the WAN address and the second plurality of identification information items; and comparing the first hash value to the second hash value to confirm that the validation data was received from the second computer system.
  • the present invention also provides a process for secure communications, the process being executed by a first computer system, and including: storing session validation data for a plurality of users and computer systems, the session validation data including: first computer authentication data representing information at least nominally unique to a plurality of second computer systems; and first user authentication data to authenticate users of said computer systems, each said user being associated with at least one of said second computer systems; receiving second user authentication data and second computer authentication data from a user of a computer system; and establishing a user session with said user only if: comparison of the first and second user authentication data authenticates the user; comparison of the first and second computer authentication data authenticates the computer system; and the stored session validation data indicates that the user is associated with the computer system.
  • the present invention also provides a system having components configured to execute any one of the above processes.
  • the present invention also provides a computer-readable storage medium having stored thereon programming instructions for executing any one of the above processes.
  • the program includes programming instructions configured to generate timestamps associated with each sending to the remote computer system and to send the generated timestamps to the remote computer system to enable the timestamps to be compared for validation purposes.
  • the computer program is configured to draw shapes and text on a display of the client computer system based on shape data received from the remote computer system, the shapes and text appearing to be graphical user interface objects to a user of the client computer system, and being drawn by the computer program to hide the graphical user interface objects from other processes executing on the client computer system.
  • the shapes and text appear to be at least one window.
  • the shapes and text appear to be at least one window having one or more interactive controls.
  • the shapes and text appear to be at least one window having one or more user input fields.
  • the shapes and text appear to be at least one window having one or more text boxes to receive user input.
  • the computer program is configured to maintain, in volatile memory of the client computer system, display data representing the shapes and text drawn on the display, and to encrypt the display data stored in the volatile memory to hide the display data from other processes executing on the client computer system.
  • the computer program is configured to associate user interaction events with at least one of the shapes drawn on the display and to redraw at least the at least one shape to give the appearance of a graphical user interface object responding to said user interaction events.
  • the computer program is configured to associate keyboard events with at least one of the shapes appearing to be a text box, and to draw corresponding text within said shape to give the appearance of a text box responding to said keyboard events.
  • the computer program is configured to receive executable code from the remote computer system, the executable code being configured to handle user interaction with the shapes drawn on the display.
  • the computer program is configured to process user interaction events to determine user input data provided by a user of the client computer system, and to send the user input data to the remote computer system for processing.
  • the computer program is configured to receive executable code from the remote computer system, the executable code being configured to associate user interaction events with at least one of the shapes drawn on the display and to redraw at least one shape to give the appearance of a graphical user interface object responding to said user interaction events.
  • the executable code is in the form of at least one dynamic link library (DLL) or script.
  • DLL dynamic link library
  • the computer program is enabled to perform transactions on behalf of said user only if the remote computer system determines that the computer system is known to the remote computer system, and the user is authenticated with respect to that known computer system.
  • Figure 1 is a block diagram showing one embodiment of a secure communication system
  • Figure 2 is a block diagram of a standard computer system of the secure communication system
  • Figure 3 is a schematic diagram of a client application of the secure communication system
  • Figure 4 is a block diagram of a core module of the client application and a shared interface module that controls access to the core;
  • Figure 5 is a flow diagram of a secure communication process of the system
  • Figure 6 is a flow diagram of an initial validation process of the secure communication process
  • Figure 7 is a flow diagram of a secondary validation process of the secure communication process
  • Figure 8 is a flow diagram of a tertiary validation process of the secure communication process
  • Figure 9 is a flow diagram of a simple example of a communication process of the secure communication process.
  • Figure 10 is a flow diagram of a more typical example of a communication process of the secure communication process, such as an invoice payment or Internet banking;
  • Figure 1 1 is a flow diagram illustrating the steps involved in each exchange of information between the client application and the server;
  • Figure 12 is a screenshot of an invoice payment virtual window generated by the client application from window data received from the server;
  • Figure 13 is a schematic diagram illustrating the random distribution of DLLs in available memory of the client system
  • Figure 14 is a flow diagram of a window message handling process used to process window messages received from the operating system
  • Figure 15 is a schematic diagram illustrating the relationships between different virtual windows created on the client system 102; and Figure 16 is a block diagram showing an alternative embodiment of a secure communication system having separate login and authorisation servers.
  • a system 100 for secure communication includes a client system 102 and a server 104 interconnected by a communications network 106 such as the Internet.
  • the system 100 executes secure communication processes, as shown in Figures 5 to 1 1 , that greatly enhance the security of communications between the client system 102 and the server 104.
  • the server 104 may itself communicate on behalf of the client system 102 with remote processing or transaction systems 108 which may include, for example, financial transaction systems operated by financial institutions, allowing financial transactions to be performed on demand.
  • the client system 102 and the server 104 are standard computer systems such as Intel IA-32 based computer systems, and the secure communications processes are implemented as programming instructions of software modules 1 18, 120 stored on computer-readable non-volatile (e.g., hard disk, solid-state drive, flash memory, and/or optical disk) storage 202 associated with the computer systems 102,104.
  • computer-readable non-volatile e.g., hard disk, solid-state drive, flash memory, and/or optical disk
  • at least one or more portions, and possibly the entirety, of the secure communications processes could alternatively be implemented in the form of one or more dedicated hardware components, such as application-specific integrated circuits (ASICs) and/or field-programmable gate arrays (FPGAs), for example.
  • ASICs application-specific integrated circuits
  • FPGAs field-programmable gate arrays
  • the client system 102 and the server 104 each includes standard computer components, as shown generically in Figure 2, including random access memory (RAM) 204, at least one processor 206, and external interfaces 208, 210, 212, all interconnected by at least one bus 214.
  • the external interfaces include universal serial bus (USB) interfaces 208, at least one of which is connected to a keyboard 216 and a pointing device such as a mouse 218, a network interface connector (MC) 210 which connects the computer system 102, 104 to the communications network 106, and a display adapter 212, which is connected to a display device 220 such as an LCD panel display.
  • USB universal serial bus
  • MC network interface connector
  • client system 102 and the server 104 are both represented generically in the block diagram of Figure 2, it should of course be understood that these two computer systems are unlikely to have identical components in the sense that, for example, the CPU or CPUs 206 of the client system 102 are likely to be different from the CPU or CPUs 206 of the server 104, and it should be understood that the same reference numerals and block diagram are used herein simply for the sake of convenience, and should not be taken as implying any further similarity between the computer systems.
  • the computer systems 102, 104 also include a number of standard software modules, including operating systems 122, 124 such as Microsoft Windows.
  • the client system 102 may also include a standard web browser application 126 such as Internet Explorer (IE).
  • the server 104 also includes web server software 128 such as MicrosoftTM Internet Information Services (IIS) or Apache HTTP server, the latter available from http://www.apache.org, scripting language support 130 such as MicrosoftTM ASP, ASP.NET, or PHP, the latter available from http://www.php.net, and structured query language (SQL) support 132 such as MySQL, available from http://www.mysql.com, which allows data to be stored in and retrieved from an SQL database 134.
  • IIS Internet Information Services
  • Apache HTTP server the latter available from http://www.apache.org
  • scripting language support 130 such as MicrosoftTM ASP, ASP.NET, or PHP
  • SQL structured query language
  • MySQL structured query language
  • the web server 128, scripting language module 130, and SQL module 132 provide the server 104 with the general ability to allow users of the Internet 106 with standard computing devices equipped with standard web browser software to provide data to and receive data from the database 134.
  • the secure communications processes will now be described in the context of a typical user of the Internet wishing to perform secure transactions with a financial institution over the Internet 106 (e.g., Internet banking).
  • the user is assumed to have in his or her possession a standard personal computer, being in this case the client system 102, but initially without the client application 1 18.
  • the user downloads a copy of an executable software application dedicated to conducting transactions for the desired financial institution.
  • the software application is downloaded to the client system 102 by the user in the standard manner using the web browser application 126.
  • the software application may be provided in stored form on a removable storage medium such as a CD-ROM, DVD-ROM, or USB-based flash memory device, or downloaded directly in executable form, compressed within a zip file, or provided as part of a Microsoft WindowsTM setup package. Irrespective of which form the application is downloaded in, once installed, the result is the executable client application 118 stored on non-volatile storage 202 of the client system 102.
  • the client application 118 constitutes a secure graphical user interface (GUI) engine.
  • GUI graphical user interface
  • the secure communications process begins when the user executes the client application 118 on the client system 102, in the standard manner.
  • an initial validation process 504 is executed.
  • the initial validation process 504 begins at step 602, when the client application 1 18 generates a 32-bit random number, referred to for convenience herein as rand, a pair of encryption keys for asymmetric encryption (i.e., a public key and a private key) for this session, and an initial timestamp, being the local time according to the operating system 122 of the client system 102.
  • rand a 32-bit random number
  • a pair of encryption keys for asymmetric encryption i.e., a public key and a private key
  • an encrypted message is generated by encrypting rand, the client application's newly-generated public encryption key for this session, the initial client timestamp, the client system 102's LAN IP address (i.e., the IP address assigned to the client system's network interface 210), and a unique identifier of the client application 1 18.
  • the latter is a variable that uniquely identifies the client application 1 18 from other related client applications, as described further below, and also the specific version number of the client application 1 18.
  • the encryption is performed using an asymmetric block cipher with the server 104's public encryption key.
  • the encryption is performed using an RSA-AES algorithm, but it will be apparent to those skilled in the art that a wide variety of asymmetric block ciphers can be alternatively used.
  • the RSA-AES algorithm used by the system operates by (symmetrically) encrypting each message using a randomly generated (for each session) 256-bit AES key, and the AES key is encrypted using the RSA public key of the message recipient. The AES-encrypted message and the RSA- encrypted AES key are then sent together to the recipient.
  • the client application 1 18 sends one or more IP packets containing the encrypted message and a hash of the message to the server 104 using HTTPS; i.e., HTTP over a 128-bit SSL channel.
  • the server 104 receives this from the client system 102, and determines the corresponding WAN IP address associated with the client system 102 from the IP packet header.
  • the server 104 decrypts the encrypted message using its private key, and at step 607 generates a random number server_rand for this session.
  • the client's LAN and WAN IP addresses, rand, server_rand, the client application's public encryption key for this session, the initial timestamp, and the client application identifier are stored in the server's database 134.
  • the WAN IP address associated with the client system 102 is likely to be that of a router or firewall WAN network interface, rather than the address assigned to the actual network interface 210 of the client system 102 itself, which is typically a non-routable address translated by the router or firewall using network address translation (NAT).
  • NAT network address translation
  • neither the LAN IP address nor the WAN IP address by itself identifies the client system 102; however, the combination of the WAN and LAN IP addresses should be unique.
  • the rand value serves as a session identifier for communications between the client system 102 and the server 104.
  • the server 104 generates a new hash value from the new data to be returned to the client (in this case, including the client WAN IP address) and all of the information received from the client system 102, and at step 614, the server sends a message containing the resulting hash value and the client system WAN IP address to the client application 118.
  • the message Prior to sending, the message is encrypted using the public key generated by the client system 102 for this session so that, in theory, only the client system 102 can decrypt the message.
  • the client application 1 18 generates a cryptographic hash value from the client LAN & WAN IP addresses received from the server 104, the client system 102's public encryption key for the session, rand, and the initial client timestamp, the latter values being retained only in the client system 102's volatile RAM 204.
  • the client application 118 compares the generated hash value to the hash value received from the server 104. If, at step 620, it is determined that the hash values are not equal, then this suggests that the client LAN and/or WAN IP address has been tampered with during transit across the Internet 106. Consequently, the initial validation fails, and the client application is terminated at step 508. Otherwise, the validation is successful, and the secure communications process proceeds to step 510.
  • the initial validation process 504 reduces the likelihood of a malicious user tampering with the packets being exchanged between the client system 102 and the server 104.
  • the client application 1 18 collects information on the client system 102.
  • the client information includes the operating system 122's LOCALE information (including time zone, local currency, and the like), and information that is at least nominally unique to the hardware components of the client system 102.
  • LOCALE including time zone, local currency, and the like
  • information that is at least nominally unique to the hardware components of the client system 102 For example, the inventor has determined that there are typically over thirty items of at least nominally unique information that can be gathered by the client application 118 in order to uniquely identify a standard personal computer system from other computer systems.
  • This information includes unique identifiers such as software-accessible serial numbers on hardware components including disk drives, peripherals, and the CPUs 206, the MAC address of the computer's network interface, and the BIOS UUID. It will be apparent to those skilled in the art that serial numbers associated with software installed on the client system 102 could also be included in this information, although such information is in general less reliable, and consequently is not used in the described embodiment.
  • Every specific item of information that the client application 188 attempts to determine is associated with a unique identifier generated by the client application 188, in the described embodiment being simply an associated item number, whereby the first item of information that is attempted to be determined is labelled as item 1 , the second is item 2, and so on.
  • the retained client information is stored only in the volatile RAM 204 of the client system 102 (and in encrypted form, as described below) and is never stored on non-volatile storage 202 of that system 102, except possibly where inadvertently by way of virtual memory being swapped out to disk 202 by the operating system 122.
  • this and other information/data used by the client application 118 is encrypted in RAM 204, as described below.
  • the information is hidden from other processes executing on the client system 102, protecting it from malicious processes or users that might try to obtain this information by scanning the client system 102's nonvolatile storage 202 or even its volatile RAM 204.
  • the client application 118 sends the LOCALE information, the collected client information, and a new (current) timestamp to the server 104, again as an RSA-AES- encrypted message sent over an SSL channel.
  • the server 104 uses this encrypted message to perform a secondary validation process 515, as shown in Figure 7.
  • the secondary validation process 515 begins at step 702, when the server 104 receives the encrypted client information, and the client system 102's current timestamp. After decrypting the message using its private key, the server 104 performs validity checks on the timestamp values at step 704.
  • the server 104 checks that the new timestamp is greater than the most recent previous timestamp, and that the difference between them is less than a configurable maximum session time, which by default is 20 minutes. 1 1 will be apparent that other constraints could additionally or alternatively be put on the timestamps in order to reduce the likelihood of man-in-the- middle and replay attacks being made on the server 104 and to ensure that each data packet will not be processed more than once.
  • the client application 1 18 sends a message to the server 104
  • the client information is sent in a doubly encrypted form, first by asymmetric encryption using the server 104's public key, and then via HTTP over a 128-bit SSL channel, and that the server 104 (after performing the appropriate tasks in accordance with the received message, resulting in a corresponding response value) generates a cryptographic hash from the response value and the client-supplied values received from the client 102 so that the client application 1 18 can verify the hash value on receipt.
  • These are sent to the client system 102 in a message encrypted with the client system 102's public encryption key for this session.
  • a generic representation of each exchange between the client system 102 and the server 104 is shown in Figure 1 1.
  • test at step 704 determines that the client-supplied timestamps do not meet the validity criteria, then a validation failure indication is returned to the client application 1 18, and the validation test at step 516 causes the client application 1 18 to self- terminate at step 508.
  • step 704 the secondary validation process 515 of Figure 7 proceeds to step 706, where the new client timestamp is stored in the database 132, effectively in a transaction table associated with the session, as now represented by the LAN & WAN IP addresses associated with the client system 102, the client timestamps, and the random numbers rand and rand_server respectively generated by the client application at 118 at step 602 and by the server 102 at step 607.
  • the server's database 134 is searched for previously stored client information matching the client information in the received message, as described further below. If, at step 710, a match is not found, then the client system is not registered with the server 104, and an indication of this is returned to the client application 1 18 at step 712.
  • the test performed at step 516 determines that the client system 102 is not registered with server 104, and consequently at step 520 the server 104 generates a unique identifier, stores it in the database 134 together with the supplied client information, and sends it, together with unknown machine window data, as will be described further below, to the client system 102, and at step 522 the client application 118 uses this data to generate and display, as described below, an unknown machine window on the display 220 of the client system 102, informing the user that the client system is not registered and displaying contact details (e.g., a telephone number) and the unique identifier to allow the user to register the client computer, and, if necessary, the user themselves, with the server 104.
  • a print button of the displayed window allows the user to print a hardcopy of the unique identifier and a timestamp.
  • the user of the client system 102 contacts an authorised customer service agent by telephone using the displayed telephone number to provide the unique identifier and personal registration information, for authentication to the server 104.
  • the customer service agent may provide the user with a validation code that the user can then type into a textbox on the displayed window in order to allow them to proceed further.
  • the customer service agent may remotely authorise the (user and) client system 102 to proceed further. In either case, the approval may be temporary and may be of a limited nature until further validation checks can be performed, as described below.
  • the personal registration information is reviewed and various off-line or out-of-band security and validation checks are undertaken in order to approve the user's use of the secure communication system 100 (and, where appropriate, the financial transaction systems 108), before the user is formally registered with the server 104 by storing the personal registration information in the database 134.
  • this personal validation step requires the user to physically present themselves, together with personal identification and a hardcopy of the printed unique identifier, to a customer service representative. If the new user represents or is registering on behalf of a business or company, the checks include checking the existence and status of that business or company with an appropriate authority. In Australia, those checks are made with the Australian Securities & Investments Commission (ASIC).
  • ASIC Australian Securities & Investments Commission
  • a validation code is provided in an email message sent to the user's registered email address and/or in an SMS message sent to the user's mobile telephone number.
  • the user provides identification information to the customer service agent and, once the identification of the user has been verified, a validation code is provided in an SMS message and/or in an email message sent to the user's original registered email address, allowing the user to reject the second registration attempt.
  • the client application 1 18 is then again executed on the client system 102 in order to repeat steps 502 through 515, as described above.
  • the step at 516 establishes that the client system 102 has been registered with the server 104, and consequently the process proceeds to perform a tertiary validation process 530, as shown in Figure 8.
  • the client application 118 sends a tertiary validation request to the server 104, and at step 804, the server 104 replies to the request with login window data, as described further below.
  • the client application 1 18 uses the login window data to generate and display a login window on the display device 220 of the client system 102.
  • the login window includes username and password text boxes, and the user enters their registered username and password into these, and clicks a "submit" button in order to submit those values to the server 104 at step 808.
  • the emailed validation code is also input into the login window and submitted to the server 104.
  • no email is sent, but the user is asked to log onto the server 104 from the originally registered computer (client system 102), as described below, and then asked to accept or reject the new registration.
  • the server 104 receives the client application's doubly-encrypted message, and decrypts the message to determine the username and password entered by the user at step 810.
  • the server 104 checks its database to determine whether the username- password pair matches a pair stored in the database 134. If not, then a validation failure message is returned to the client application 1 18 at step 816. Otherwise, if a matching username-password pair is found, then a further test is performed at step 814 to determine whether both of the username password pairs are associated with the same physical computer. This is determined by comparing the locale and unique client information provided to the server at step 514 with the client information provided during the registration process at step 526. If the information does not match, then it may be that the user is valid, but they are not using the same computer that they registered with the server 104. Alternatively, this may indicate that a malicious user has somehow determined the real user's username and password, and is attempting to use it on a different computer to access the real user's account.
  • a validation failure message is returned to the client application 1 18 at step 816, causing it to terminate at step 508.
  • a representative of the organisation operating the server 104 could telephone the user associated with the username being used in the login attempt to confirm that they are in fact trying to login to the server 104 and, if so, explaining that they are attempting to do this from a computer that has not been registered in association with their username.
  • a second telephone call is made to a user who is registered in association with the computer whose unique identification information is being repeatedly provided to the server 104, asking the user to confirm that there is a person trying to login from that registered computer system and, if so, to identify that person so that appropriate action can be taken.
  • the tertiary validation process succeeds at step 532, thus completing the three validation processes 504, 515, and 530, and secure communications can now proceed at step 534, as described below.
  • the client application 1 18 self-terminates at step 508, thus completing the secure communications process.
  • the processes described above greatly reduce the likelihood that a hacker can successfully compromise the secure communications processes 534.
  • the messages sent from the client application 118 to the server 104 are all doubly-encrypted, firstly by asymmetric encryption using the server 104's public key, and then with 128-bit SSL, which should in theory secure the communications across the Internet 106 in any case.
  • the use of the initial and subsequent timestamp validity checks, and the random number generated by the client application 1 18 and required in each communication of a session all greatly reduce the possibility for man-in-the-middle and replay attacks.
  • secure communications can take place at step 534.
  • the nature and types of secure communications at step 534 are entirely customisable, depending on the desired functionality that is to be provided to the user.
  • the secure communication simply involves the client application 118 sending a request to the server 104 to store user supplied data in a database (e.g., the database 134 or another database), and/or to retrieve data from a database and return it to the user.
  • a database e.g., the database 134 or another database
  • the secure communications process and system effectively implement their own window system independent of any other software of the client system 102, including window and widget creation and management processes that allow the creation and management of interactive communications using window-based graphical user interface (GUI) components that may appear to be standard GUI components, and yet are implemented in an independent and secure manner.
  • GUI graphical user interface
  • a very simple interactive communication may involve the client application sending a request to the server for window data.
  • the client application 1 18 receives the window data from the server 104, and at step 906 uses it to generate and display at least one window on the client system 102's display device 220. This simple communication simply displays information to the user, but in a secure manner, as described further below.
  • FIG. 10 shows a server-side secure processing or transactional process which may be, for example, Internet banking, or payment of an invoice, subscription, or the like.
  • the client application requests at least one script, or alternatively dynamic link library (DLL), and corresponding window data from the server 104, and at step 1004, this is received from the server, and stored only in volatile storage of the client system 102, i.e., its RAM 204, and in encrypted form.
  • the client application 1 18 uses the window data to generate and display at least one window on the client system 102's display 220, as described in detail below.
  • DLL dynamic link library
  • the result is a window 1200 such as that shown in Figure 12, which includes text boxes 1202 to 1210 into which the user can enter payment information, such as an invoice number identifying the particular invoice to be paid, the amount that is to be paid, and the payer's credit card details.
  • Pull down menu 1212 allows the user to select the type of transaction, and pull down menus 1214, 1216 allow the user to specify the credit card expiry date.
  • Logical functions that require the window to change in response to user input are handled by the script or DLL associated with that window.
  • the client application 118 executes the scripts and/or DLLs.
  • An important aspect of the secure communications system is that, once the window data (and any associated script or DLL) has been downloaded from the server 140 to the client system 102, the network connection between the client system 102 and the server 104 is closed, and no further communication takes place between the client system 102 and the server 104 while the user interacts with the displayed window(s).
  • the user interaction is entirely managed by the client application 102 (including any script/DLL used by the client application 102) executing on the client system 102. Further communication does not take place until the user submit the information entered into the interactive window (via any textboxes, menus, radio buttons, and the like) in the usual manner by selecting a "submit” or "OK” button, at which time the information is encrypted and sent to the server as described further below.
  • a Process button 1218 can be pressed to submit the user information to the server 104 as step 1010.
  • the server 104 performs the required processing or transaction, which in this case involves submitting the payment information entered by the user to a financial system or payment gateway 108 in order to pay the invoice (or bill or subscription etc., as the case may be).
  • the server 104 returns the transaction status and identifier to the client application 1 18, together with further window data that the client application 1 18 uses, at step 1016, to generate a result window showing the result of the transaction to the user.
  • step 1010 If the user wishes to conduct a further transaction (indicated by selecting an appropriate control in the displayed result window or payment window, it still displayed), the process loops back to step 1010. Otherwise, the transactions are complete and the secure communications of Figure 10 are complete and the process returns to step 508.
  • the secure communication system is not constrained to use any pre-defined fields or visual layout of those fields, but can provide any desired fields in an invoice (or other type of form) and in any desired arrangement or layout. This provides a great advantage over existing payment systems, where invoice forms are generally provided in a fixed form that cannot be modified to suit the needs of different payees.
  • the secure communication system 100 and processes described herein greatly reduce the likelihood that a malicious user would be able to perform many forms of attack, including those described above.
  • the window data that actually causes each window and its associated GUI components to be generated are never stored in non-volatile storage on the client system 102 itself, but are only dynamically downloaded on demand and temporarily retained in the client system's volatile RAM 204.
  • the window data that define properties of the window itself, the text boxes, pull down menus buttons, and other controls are also dynamically downloaded, and code handling any complex interactions is included in the script/DLL that is also dynamically downloaded with the window data, and is never stored on non-volatile storage associated with the client system 102.
  • the only relevant application that is stored on the client system 102 is the client application 1 18, which does not include any of the payment window or logic information.
  • the secure communication system protects against such attacks in two ways. Firstly, as shown in Figure 13, as described above, the window data received from the server 104 defines one or more windows and includes one or more DLLs and/or scripts, one for each window to handle user interaction with that window.
  • the client application 1 18 distributes these DLLs (or scripts) randomly throughout the computer's available memory, as shown in Figure 13.
  • window data received from the server 104 defining three windows also includes three corresponding DLLs 1302, 1304, 1306 that are located at randomly selected portions of the client system 102's RAM 204.
  • the client application 1 18 maintains a function table 1308 storing pointers to the DLLs, so that each DLL can be located when required to process user interaction with its associated window. It is therefore difficult for a hacker to locate the DLL for a particular window, and even if one of the DLLs is found, the other DLLs remain distributed at unknown locations in RAM 204.
  • the secure communication system 100 does not use the window controls, objects, or functions provided by the windowing or operating system 122, but rather effectively implements its own graphical user interface objects (including windows, widgets, controls, etc) and management processes in an entirely independent and private manner and contained within the address space of the executing instance of the client application 1 18. This is achieved by drawing these onto the display 220 as shapes and text, and manages user interactions with these drawn shapes using encrypted data stored only in volatile RAM 204 of the client system 102, and independently of any system libraries or functions for creating, identifying, and/or handling such objects. Thus from the point of view of the windowing or operating system 122, or indeed a malicious program looking for window object or control data structures, these objects and controls do not exist.
  • window objects are simply drawn as shapes on the display 220, the windows and their constituent objects generated by the secure communications processes are referred to herein as 'virtual' windows and window objects, since they have no existence as objects outside the memory space of the executing client application 118, and even in that memory space are not stored as standard object data structures that could be easily identified by an attacker.
  • the secure communication system 100 does not store the window and window object properties and associated data in standard window data structures, but rather as an encrypted array of variables in memory.
  • the array is temporarily decrypted and the required variables are copied to another location in memory where they are used as desired, and then overwritten in memory. If any updates to the variables are required, these can be written back to the array, which is then re-encrypted again.
  • a separate process thread periodically monitors the encryption state of the encrypted array, and re-encrypts the array after a configurable time period has elapsed since the last encryption (by default, every second) if it is found to be unencrypted.
  • the array is encrypted using the Tiny Encryption Algorithm, or TEA, as described in Wheeler, David J.; Needham, Roger M. (1994-12-16), "TEA, a tiny encryption algorithm", Lecture Notes in Computer Science 1008: 363-366. Leuven, Belgium: Fast Software Encryption: Second International Workshop.
  • TEA Tiny Encryption Algorithm
  • the client application 1 18 includes a main component or module 302, a render module 304, an event module 306, a transport module 308, a core module 310, and various interface modules 312 to 320.
  • the main module 302 is the initial entry point for the client application 118, and its main purpose is to initialise a standard window object (effectively used only to provide a drawing canvas) using a standard operating system API, and to specify an associated call back function (WindowProc, in the case of a Microsoft Windows operating system) to handle some of the window messages generated by the operating system 122, as described below.
  • WindowProc in the case of a Microsoft Windows operating system
  • the rendering module 304 provides all of the drawing functions that are used for rendering virtual graphical user interface objects on the client system 102's display 220.
  • the transport module 308 includes all of the functions that communicate with the server 104, including the various security validation checks and processes described above.
  • the core module 310 stores all of the global variables for the client application 1 18, and these can only be accessed via the shared interface module 320, which can be accessed by any of the other modules 302 to 308.
  • the core 310 includes different groups of variables.
  • User/data input variables 406 include variables storing data that represents the user's current selection and message information (identifying an event, such as a keypress, mouse button down, and the like) for the user's input.
  • ShapeCollection 408 is a collection of shape objects 410, each shape 410 representing one virtual object (e.g., the virtual window itself, a textbox, menu, button, etc) associated with a virtual window.
  • Each shape object 410 includes a paint data structure 412 used for rendering, and a save data structure 414 that contains the information to be sent to or received from the server 104.
  • the event component 306 is responsible for detecting, routing, and triggering events in the system 100.
  • the event module 306 detects an event, it calls the corresponding DLL/Script Interface 404 first, and then calls the normal interface 402.
  • the shared interface module 320 provides two different interfaces: a normal interface 402 and a DLL/Script interface 404, which provide access to different variables within the core module 310.
  • the normal interface 402 provides access to all of the core variables, but the DLL/Script interface 404 can only access the save data structures 414.
  • the client application 1 18 generates and displays virtual windows on the client system 102's display 220, based on window data received from the server 104.
  • the window data is a list of attributes that defines the location, dimensions, and type of each virtual window component object within the virtual window, including buttons, check boxes, pull down windows, text boxes, background colour rectangle 1213 and so forth, as shown in Figure 12.
  • the window data specifies the type of each object, the pixel coordinates of the top, bottom, left and right edges of that object, any actions associated with that object, and various other attributes.
  • the attributes include Boolean attributes defining whether or not the window object has a titlebar, a menubar, and a status bar, and, where appropriate, attributes defining the window border width, border colour, border colour gradient, and so on.
  • the client application 1 18 draws these graphical user interface components on the display 220 as appropriate. Coordinates are either absolute screen (pixel) coordinates or, where an object is subordinate to another object (e.g., a button within a window), relative to the parent object.
  • the action field specifies at least one action to be performed when selecting the object.
  • the action associated with a button can be an instruction for the client application 1 18 to draw the next virtual window (where the received window data defines more than one virtual window), or it can be an instruction or message for an external application, such as MailTo or HTTPto, and the like.
  • window data defining a typical window such as that shown in Figure 12 is about 32 kilobytes uncompressed, and about 1.8 kilobytes when compressed.
  • the window data defining each virtual window and its components is stored in compressed form on the server 104, as are the DLLs used to handle user interaction with those components.
  • the compression is performed using the standard zip compression utility.
  • the client application 118 decompresses the window data and the DLLs in RAM 120 using the standard unzip decompression utility.
  • the client application 1 18 draws all of the (virtual) window components itself as shapes and text (as opposed to objects managed by the operating system or window system)
  • the only component that the operating system 122 is aware of is the startup window itself, which is only used to initialise a (full screen, in the described embodiment) canvas for drawing on and, depending on the specific client operating system 122, to specify a callback function (referred to generally as WndProc in Microsoft WindowsTM operating systems) so that the operating system 122 will send window events directly to that function.
  • all the components within the window although they may look identical to standard widgets, controls and other graphical user interface objects or components provided by the windowing system or operating system 122 itself as the case may be, depending on whether the windowing system is effectively a part of the operating system (as in Microsoft WindowsTM or Apple Inc.'s Mac OSTM, or executes on top of it, as in UnixTM-based operating systems which normally use the X Window System to provide a windowing environment), are actually only shapes and text drawn on the display screen and accessible to and managed by the only client application 118, and, where a DLL/script is also downloaded from the server 104, events requiring complex processing being handled by that DLL/script.
  • the client application 118 uses the render module 304 to draw the widgets, controls, and text on the screen as lines and shapes.
  • the operating system 122 is a Microsoft WindowsTM operating system
  • events occurring within a virtual window are processed as shown in Figure 14.
  • a generic Windows program can create a new window by first registering a window class defining, amongst other things, the Window Procedure, often referred to generically by Windows programmers as windowProc, winProc, or WndProc (but can have any name), that will be used to handle messages for windows under that class, and then calling the CreatewindowQ function to create a new window using that class.
  • Window Procedure often referred to generically by Windows programmers as windowProc, winProc, or WndProc (but can have any name)
  • this standard model is modified by using a heuristic procedure to efficiently generate and handle simple user interaction events on virtual window objects; other events are passed to the Window Procedure associated with the window class so that other events can be handled in the usual manner.
  • the heuristic procedure involves three steps: detection, routing, and triggering. Because the operating system 122 does not know that any of the virtual window objects exist, a Heuristic module 1404 uses a detection procedure to translate system events into events for virtual window objects. A routing and triggering module 1405 then routes and triggers those events, as described below.
  • the overall message handling loop of Figure 14 operates as follows. On invocation, the loop simply waits at step 1402 (GetMessage()) to receive the next window event from the operating system 122. Once an event has been received, the heuristic module 1404 is used to determine whether the event should be interpreted as a virtual window event and, if so, to translate the event to a virtual window object event and efficiently route and trigger the virtual window event in the shared interface module 320 which updates the variables of the core 310. Altematively, the operating system 122 can directly route messages to the Event Handler 1406.
  • the shared interface module 320 If the shared interface module 320 identifies an event as requiring the corresponding virtual window to be re-rendered, it first updates the core 310, and then generates a render event that the operating system sends directly to the WndProc() event handler 1406, which invokes the render module 304. This causes the rendering module 304 to paint the virtual window according to the data in the core 310.
  • a virtual window that requests another virtual window from the server 104 is typically deemed to be a parent of that requested window, even where those windows are associated with different organisations, although ultimately this is determined by the window data downloaded from the server 104.
  • access restrictions apply to the virtual windows created by the client application 1 18, as defined by the following rules: (i) Rule 1 : a virtual window can only access (change the status of) its children and has access to its parents only if the parent grants permission (client Side).
  • Rule 3 parent and child virtual windows can be from different organization, but Rule 1 and Rule 2 are applied on this condition. (Client side)
  • Figure 15 is a schematic diagram illustrating the relationships betweenfive virtual windows VWl to VW5.
  • Rule 1-3 means that VW 5 can only access VW4 and VW2.
  • VW2 can only access its children VW3, VW4, and VW5.
  • VW 3 can only access VW 2, even though it is associated with the same organisation as VWl).
  • the client application 1 18 has been described above as being dedicated to a particular service or organisation (e.g., Internet banking for a particular bank, for example), in another embodiment the client application 1 18 is used as a gateway to a wide variety of different services/applications.
  • the server 104 downloads window data and a DLL/Script that allow the user to select one of a wide variety of different services/applications, and on submission of that selection back to the server 104, the server then transmits the corresponding window data and DLL/script to allow the user to execute the selected service/application.
  • the server 104 downloads window data and a DLL/Script that allow the user to select one of a wide variety of different services/applications, and on submission of that selection back to the server 104, the server then transmits the corresponding window data and DLL/script to allow the user to execute the selected service/application.
  • the server 104 downloads window data and a DLL/Script that allow the user to select one of a wide variety of different services/applications, and on submission of
  • the server 104 is replaced by two servers: an authorisation server 1602, and a login server 1604, with the functions of the server 104 described above being divided between these two servers 1602, 1604.
  • the three components 102, 1602, 1604 all communicate via a communications network 106, such as the Internet, but for convenience of description the communications between these three components are shown in Figure 16 to illustrate the three-way nature of these communications.
  • the operation of the secure communications system shown in Figure 16 is mostly the same as the processes system described above, but with a few significant differences in the nature of communications arising from the division of the server 104 into distinct authorisation 1602 and login 1604 servers.
  • the client application 1 18 generates a new pair of public and private encryption keys for each session.
  • each of the authorisation server 1602 and the login server 1604 has its own pair of public and private encryption keys for secure communications.
  • the initial validation process 504 described above is executed as before to initialise the session parameters, and the secondary validation process 515 described above is also executed to verify that the client system 102 is registered with the authorisation server 1602, and that the timestamps on the various communications are consistent to prevent replay attacks and the like.
  • the (tertiary) validation of a user of the client system 102 is performed in this embodiment by the login server 1604 in conjunction with the authorisation server 1602, as follows. Firstly, session information, including the initial timestamp indicating when the client application 1 18 was executed, the client system 102's session variable rand, and the authorisation server 1602's session variable server_rand are encrypted by the authorisation server 1602 using the login server 1604's public encryption key, and this encrypted message is itself encrypted once again using the client system 102's public key for the session, and sent to the client system 102 over SSL.
  • the doubly encrypted message (triply encrypted if one includes the SSL encryption) is decrypted once time by the client system 102, using it's private key. The resulting singly encrypted message cannot be decrypted by the client system 102, which simply forwards the encrypted message over another SSL connection to the login server 1604.
  • the login server then decrypts the message using its private encryption key to determine the session variables described above.
  • the login server 1604 sends a further message directly to the authorisation server 1602 with the session variables so that the authorisation server 1602 can verify that the client system 102 is appropriately authorised to proceed to user validation.
  • the encrypted message is in this case encrypted using the authorisation server 1602's public encryption key, and sent over SSL.
  • the authorisation server 1602 compares the session variables received from the login server 1604 with those stored in its database, and therefore determines whether the user validation request seems to be valid.
  • the login server 1604 sends window data that causes the executing client application 1 18 to generate a login or authorisation window prompting the user to enter their username and password as stored in the login server 1604's database 1612 to verify that the user is authorised to proceed with secure communications 534.
  • the secure communication system could be used to provide validation and secure communications between a variety of different organisations.
  • the authorisation server 1602 and the login server 1604 can be used to provide secure communications with, for example, the organisation operating the secure communications system.
  • other organisations can provide their own equivalent to the login server 1604 so that, while machine and organisation-specific validations can be performed as described above, the actual user validation is specific to each organisation's login server, corresponding to the particular user's account with that organisation.
  • a different login server is operated by a bank or other financial institution
  • that other login server can still communication with the authorisation server 1602 of Figure 16 to provide secure communications between a user of the client system 102 and the financial organisation in question.
  • This allows the financial institution to take advantage of the hidden windows provided by the secure communication system and also the multiple validation steps described above to inhibit the likelihood of hackers or other malicious users being able to tamper with communications between a valid user or to impersonate a valid user and/or a valid user's computer system.
  • the secure communications system is believed to make it extremely difficult, if not infeasible, for man in the middle or replay attacks, for example, amongst others.
  • the secure communications process and system have been described above in terms of a standard computer system executing a Windows operating system, other forms of computing systems and devices and operating systems can alternatively be used.
  • the functions provided by the client application can be implemented as embedded code in firmware of a secure client system, terminal, or device. In other embodiments, these functions are provided in an FPGA.
  • the secure communications process is used to provide secure communications to a device such as a vending machine. Where the vending machine includes an LCD display screen, information is securely transmitted to the vending machine and displayed to a user of the vending machine on that display.
  • the user can input information (e.g., credit card details, payment amount, car license plate details, the user's drivers license number, etc) using the touch screen and the secure communications process then securely transmits that information to the server 104.
  • information e.g., credit card details, payment amount, car license plate details, the user's drivers license number, etc
  • user input can be additionally or alternatively be provided by way of a card reader of the vending machine, where the user swipes or otherwise (e.g., by way of proximity or allowing access for readable devices having RFID, Bluetooth, or any other form of wireless communication) provides their credit card, bank card, driver's license card, or any other type of readable card, device, or storage medium to provide user input that is securely sent to the server 104 using the secure communications process.
  • GUI secure graphical user interface
  • GUI secure graphical user interface
  • the secure graphical user interface (GUI) engine itself acts as a server or even as a combination of client and server, and that it interacts with one or more other systems which themselves act as clients or as combinations of client and server.
  • the word 'server' as used in this specification should be understood broadly as encompassing a wide variety of different types of systems, including those that may initiate interactions with other computer systems, rather than only acting in response to requests from other computer systems.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention concerne un système de communications sécurisées comprenant un serveur et un moteur d'interface graphique utilisateur (GUI) sécurisé destiné à être exécuté par un système informatique exécutant un système d'exploitation, le moteur d'interface graphique utilisateur sécurisé étant configuré pour recevoir des données d'interface graphique utilisateur du serveur sur une connexion de réseau sécurisée, dessiner des formes représentant des composants d'interface graphique utilisateur sur un afficheur du premier système informatique conformément aux données d'interface graphique utilisateur reçues de sorte que les composants d'interface graphique utilisateur soient cachés aux autres processus du système informatique, recevoir des événements d'interaction d'utilisateur du système d'exploitation, déterminer si les événements d'interaction d'utilisateur reçus représentent des interactions d'utilisateur avec un ou plusieurs des composants d'interface graphique utilisateur, et, si c'est le cas, mettre à jour un ou plusieurs des composants d'interface graphique utilisateur pour réagir audit ou auxdits événements d'interaction d'utilisateur correspondants, déterminer des données d'utilisateur représentant des informations fournies par une ou plusieurs des interactions d'utilisateur avec ledit ou lesdits composants d'interface graphique utilisateur; et envoyer les données d'utilisateur à un serveur sur une connexion sécurisée. L’in
PCT/AU2009/000951 2008-07-24 2009-07-24 Système et processus de communications sécurisées WO2010009516A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US8346408P 2008-07-24 2008-07-24
US61/083,464 2008-07-24

Publications (1)

Publication Number Publication Date
WO2010009516A1 true WO2010009516A1 (fr) 2010-01-28

Family

ID=41569939

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AU2009/000951 WO2010009516A1 (fr) 2008-07-24 2009-07-24 Système et processus de communications sécurisées

Country Status (1)

Country Link
WO (1) WO2010009516A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030182558A1 (en) * 2002-02-05 2003-09-25 Lazzaro John R. Dynamic PIN pad for credit/debit/ other electronic transactions
US20070192608A1 (en) * 2004-03-10 2007-08-16 Agostinho De Arruda Villela Access control system for information services based on a hardware and software signature of a requesting device

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030182558A1 (en) * 2002-02-05 2003-09-25 Lazzaro John R. Dynamic PIN pad for credit/debit/ other electronic transactions
US20070192608A1 (en) * 2004-03-10 2007-08-16 Agostinho De Arruda Villela Access control system for information services based on a hardware and software signature of a requesting device

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Virtual Network Computing Wikipedia", 3 November 2007 (2007-11-03), Retrieved from the Internet <URL:http://web.archive.org/web/20071103002631/http://en.wikipedia.org/wiki/VirtualNetwork_Computing> *

Similar Documents

Publication Publication Date Title
US10904234B2 (en) Systems and methods of device based customer authentication and authorization
AU2016220152B2 (en) Cloud encryption key broker apparatuses, methods and systems
KR102402924B1 (ko) 강화된 인증을 통한 거래 검증
US9426134B2 (en) Method and systems for the authentication of a user
US8448226B2 (en) Coordinate based computer authentication system and methods
EP1710980B1 (fr) Services d&#39;authentification avec un appareil mobile
JP5619007B2 (ja) サーバ・オペレーションの認可を行うための装置、システムおよびコンピュータ・プログラム
US8051465B1 (en) Mitigating forgery of electronic submissions
US20140012750A1 (en) Systems, methods, and computer program products for integrating third party services with a mobile wallet
US20080046723A1 (en) Multi-factor authentication
US20070033136A1 (en) Secured financial transaction device
EP3271824A1 (fr) Attestation automatisée d&#39;intégrité d&#39;un dispositif à l&#39;aide d&#39;une chaîne de blocs
US20150188698A1 (en) Systems, methods, and computer program products for providing application validation
KR20130125316A (ko) 패스워드의 보안 입력 및 처리 장치, 시스템 및 방법
KR20170140215A (ko) 거래 시큐리티를 위한 방법 및 시스템
US20180262471A1 (en) Identity verification and authentication method and system
CN113015991A (zh) 安全的数字钱包处理系统
AU2009295193A1 (en) Method and system for user authentication
JP7395261B2 (ja) 仮想通貨の送金システム
CN117561508A (zh) 可验证凭证的跨会话颁发
KR20220038109A (ko) 동의 아키텍처용 인증자 앱
US20240089249A1 (en) Method and system for verification of identify of a user
CN117751551A (zh) 用于安全互联网通信的系统和方法
US20220150228A1 (en) Computer systems and methods including html browser authorisation approaches
WO2010009516A1 (fr) Système et processus de communications sécurisées

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09799874

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WPC Withdrawal of priority claims after completion of the technical preparations for international publication

Ref document number: 61/083,464

Country of ref document: US

Date of ref document: 20110124

Free format text: WITHDRAWN AFTER TECHNICAL PREPARATION FINISHED

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 140612)

122 Ep: pct application non-entry in european phase

Ref document number: 09799874

Country of ref document: EP

Kind code of ref document: A1