Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/10—Protocols in which an application is distributed across nodes in the network
  • H04L67/104—Peer-to-peer [P2P] networks
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L61/00—Network arrangements, protocols or services for addressing or naming
  • H04L61/09—Mapping addresses
  • H04L61/25—Mapping addresses of the same type
  • H04L61/2503—Translation of Internet protocol [IP] addresses
  • H04L61/256—NAT traversal
  • H04L61/2575—NAT traversal using address mapping retrieval, e.g. simple traversal of user datagram protocol through session traversal utilities for NAT [STUN]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L61/00—Network arrangements, protocols or services for addressing or naming
  • H04L61/45—Network directories; Name-to-address mapping
  • H04L61/4541—Directories for service discovery
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L61/00—Network arrangements, protocols or services for addressing or naming
  • H04L61/45—Network directories; Name-to-address mapping
  • H04L61/4552—Lookup mechanisms between a plurality of directories; Synchronisation of directories, e.g. metadirectories
• • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
  • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
• • 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
  • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
• • 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/08—Network architectures or network communication protocols for network security for authentication of entities
  • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/14—Session management
  • H04L67/142—Managing session states for stateless protocols; Signalling session states; State transitions; Keeping-state mechanisms
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/2866—Architectures; Arrangements
  • H04L67/30—Profiles
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/50—Network services
  • H04L67/56—Provisioning of proxy services
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/14—Session management
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/50—Network services
  • H04L67/54—Presence management, e.g. monitoring or registration for receipt of user log-on information, or the connection status of the users

Definitions

• the present invention concerns improvements relating to secure telecommunications and more particularly, though not exclusively, to secure peer-to-peer e-mail and data communications as well as Voice over IP.
• a further aspect of the present invention is directed towards a method of supporting direct peer-to-peer communications even when Network Address Translators (NATs) are provided to protect a communications network and amplify its IP addressing range.
• NATs Network Address Translators
• the present invention also extends to effecting the very high levels of security in such communications systems and networks using such communications systems.
• Encryption techniques are known to improve the security of e-mails which are stored during the communications process. However, no encryption technique is completely secure and so with the sophistication of hacking techniques, this does not in itself present a viable alternative.
• NATs are devices that are used to allow multiple computers to share an address space for communications, such as connecting to the Internet. They have a disadvantage which effects peer-to-peer communications in that such communications do not normally work behind a NAT without complex set ups, which are well beyond the capabilities of the average PC user.
• the problems associated with NATs in the context of peer-to-peer communications are described in US 2004/0064584 Al.
• One aspect of the present invention resides in the appreciation that the most secure peer-to- peer e-mail communications, for example, would not require any storage of the message in an insecure environment, namely at any place in the communications route other than the source or destination. In this way, there is only very small chance of a hacker reading the e- mail, namely as it is being transmitted.
• PKI Public Key Infrastructure
• a method of carrying out a secure peer-to-peer data communication such as an e-mail communication, between a first remote party computer and a second remote party computer over a data communications medium, the method comprising: receiving the address details and current status of a connection to the data communications medium of each remote party computer; creating the data communication at the first remote party computer; checking the current connection status of the second remote party computer; and sending the data communication from the first remote party computer directly to the second remote party computer without any storage of the data communication en route, only when the connection status of the second remote party computer indicates that it is currently connected to the data communication medium.
• the term 'storage' as used herein is a reference to storage of the complete message. Such storage would provide an opportunity for an unauthorised third party to obtain illegally a complete copy of the message.
• Communication protocols often include some temporary storage of part of a message, for example one which is broken down into packets. Such temporary and partial storage of part of the message is permissible with the present aspect of the present invention as it does not permit a third party to obtain a complete copy of the message being transmitted.
• the present invention provides a significant improvement over the prior art in that there is no insecure storage of the complete data message en-route from the source to the destination. Rather, even if the destination is not on-line, the message is always stored securely and temporarily at the source until such time as the peer-to-peer communications channel has been established with the destination, such that no insecure storage of the data message is required en route.
• the present invention is embodied in a system where there is a central repository of usernames and their IP addresses.
• the central repository is not used in the actual peer-to-peer communication itself, but rather serves to update the communications means provided at the sender's location.
• Users register with the central repository and are assigned names for their specific IP address. The registered user then downloads and installs a personal communications server onto their computer for facilitating peer-to-peer communications. Whenever a registered user comes on-line as determined by use of their personal communications server, the central repository is notified and the status of the user can be changed from off-line to on-line.
• This change in status can also be communicated to all other users via a push mechanism such that any peer-to-peer communications that need to be carried out between existing on-line users and the user who has just connected can be done so secure in the knowledge that both recipient and sender should at this instant be able to send and receive the communication.
• the system described above has downloaded software components resident on the client personal computer which control the messaging function. These are described in greater detail later but include for an e-mail messaging embodiment, an e-mail server which co-operates with a local e-mail client such as Microsoft OutlookTM to handle the sending and receipt of all data messages without the requirement for the user to access any central server, or in fact any user interaction.
• a local e-mail client such as Microsoft OutlookTM
• the client's personal computer is able to control the desired peer-to-peer communications and the process is very easy from the user's point of view.
• VOIP can be provided relatively easily because the user can instantaneously be notified of any people who are available for a phone conversation, namely on-line at any time as this status information is pushed-to the person wishing to make the call.
• the VOIP connection is via the Internet, it is free, such that long distance and local calls can be made without any additional charge to the standard internet connection charge paid by the user.
• the present invention allows users to send and received confidential business and personal information in total privacy. Also if the present invention is used in conjunction with conventional e-mail, the present invention provides a back up system to the conventional e-mail server, providing continuity of service in the event of a fault, disaster, physical or cyber attack.
• the present invention means that third parties such as ISPs can no longer glean private information from received e-mails about the sender and their business for advertising or other purposes. Also, no additional equipment is required such as expensive e-mail servers and the expense of technical support is also mitigated which can considerably reduce costs.
• the present invention can work through firewalls, and requires no additional configuration.
• the present invention can integrate seamlessly with existing e-mail applications, such as Microsoft OutlookTM and Novell GroupwiseTM.
• Peer-to-peer communication with an IP address is relatively easy when the IP address is the actual IP address of the recipient.
• peer-to-peer communication becomes more difficult because of the inability of the sender to uniquely identify the recipient and also because of the possible security function of the NAT as a firewall.
• Another aspect of the present invention is directed to this specific issue (described later).
• the present aspect of the present invention may also be considered to provide a communications server arranged to carry out a secure peer-to-peer data communication, such as an e-mail communication, between a first remote party computer including the server and a second remote party computer over a data communications network, the server comprising: receiving means for receiving the address details and current status of a connection to the data communications network of each remote party computer; a message generation module for creating the data communication at the first remote party computer; a checking module for checking the current connection status of the second remote party computer; and a transport module arranged to send the data communication from the first remote party computer directly to the second remote party computer without storage of the complete data communication en route, only when the connection status of the second remote party computer indicates that it is currently connected to the data communication network.
• a communications server arranged to carry out a secure peer-to-peer data communication, such as an e-mail communication, between a first remote party computer including the server and a second remote party computer over a data communications network
• the server comprising: receiving means
• the present aspect of the present invention also extends to a communications system comprising: a plurality of communication servers as described above; and a data server connectable to the plurality of communications servers by the data communications network, wherein the data server is arranged to receive, collate, and store the current status of the connection of each of the communication servers to the communications network together with the current network address of each of the communications servers and to forward at least part of this information to the plurality of communications servers to enable them to effect peer-to-peer communications between ones of the plurality of communications servers.
• a communications server arranged to assist in establishing a secure peer-to-peer data communication, such as an e-mail communication, between first and second user computers over a data communications network, the server being provided at a given hierarchical level within a server network comprised of a plurality of the communications servers, the server comprising: connection means enabling the communications server to be able to connect operably to other communications servers at other hierarchical levels within the server network; registration means for registering a plurality of local user computers with the communications server; and a data store for storing registration details of each registered local user computer, the registration details including address information and current status of a connection to the data communications network of each local user computer; wherein the connection means is arranged to forward the stored registration details to an adjacent communications server in the next higher hierarchical level of the server network and to receive and store registration details of any local user computers for a connected communications server at a lower level in the hierarchical network.
• Use of a hierarchical network of transport servers is highly advantageous because it enables a messaging network to operate more efficiently.
• the use of a hierarchical structure in the communications medium enables much of the traffic to be handled locally without placing an undue burden on the whole of the communications system.
• VoIP message traffic can have a particularly heavy payload and can use up much of the available bandwidth.
• Use of the hierarchical structure and the distributed recording of addressing details can help to localise the traffic to particular parts of the communication network thereby not effecting the performance characteristics of other parts of the network. This has a major performance benefit on, for example, VOIP communications as there most VOIP calls are between geographically local source and destinations.
• the present second aspect of the present invention also extends to a method of assisting in establishing a secure peer-to-peer data communication, such as an e-mail communication, between first and second user computers over a data communications network, the method being implemented on a communications server at a given hierarchical level within a server network comprised of a plurality of the communications servers, the method comprising: establishing operable network connections to communications servers at other hierarchical levels within the server network; registering a plurality of local user computers with the communications server; and storing registration details of each registered local user computer, the registration details including address information and current status of a connection to the data communications network of each local user computer; wherein the establishing step comprises forwarding the stored registration details to an adjacent communications server in the next higher hierarchical level of the server network and receiving and storing registration details of any local user computers for a connected communications server at a lower level in the hierarchical network.
• a method of searching for an intended recipient computer of a peer-to-peer communications message to assist in establishing a secure peer-to-peer data communication, such as an e-mail communication, between a sender computer and the intended recipient computer over a data communications network the method being implemented within a hierarchical network of communications servers and comprising: sending to a local server a request for data communication, the request including the intended recipient computer's identity and the sender computer's identity; determining whether the intended recipient is known to the local server; retrieving stored details regarding the intended recipient if the same is known to the local server, and transmitting these details back to the sender computer; forwarding the request to an adjacent communications server in a next higher hierarchical level of the server network if the intended recipient is not known locally, the adjacent communications server then becoming the local server; and repeating the determining, retrieving and forwarding steps until the intended recipient is found or the server at the summit of the hierarchical network has been checked.
• This manner of using a hierarchical communications network is advantageous in that the procedure for finding of a destination address can be considerably faster than in the prior art.
• the reason of this is that geographically local addresses to the source are checked first and gradually more and more remote addresses are checked at higher and higher positions in the hierarchical network until the address is found or the summit reached. Again as many communications are actually directed to local destinations, these can be found quickly and the potential administration burden on the network of communications servers can be avoided.
• the present third aspect of the present invention also extends to a method of establishing a secure peer-to-peer data communication, such as an e-mail communication, between a sender computer and an intended recipient computer over a data communications network, the establishing method being implemented within hierarchical server network comprised of a plurality of communications servers, the establishing method comprising: a method of searching for an intended recipient computer as described above; communicating the current global communications address of the intended recipient computer to the sender computer; communicating the current global communications address of the sender computer to the intended recipient computer; and using the global communications addresses to set up a peer-to-peer communications channel between the sender and the intended recipient computers.
• a transport server for use in establishing a peer-to-peer data communication, such as an e-mail communication, between a first and second user computers, the transport server comprising: receiving means for receiving from the first user computer a request for connection to the second user computer which is registered with the transport server; verifying means for verifying the current connection status of a connection to the second user computer; a data store for storing details of the request as a watch if the current connection status of the second user computer indicates that a peer-to-peer communication cannot at present be established with the second user computer; and response means responsive to the verifying means to send a message to the first user computer indicating the on-line status of the second user computer if the status of the same changes to indicate that a peer-to-peer communication can now be established with the second user computer; wherein the verifying means is arranged to periodically check and update the current connection status to the second user computer, and when an update indicates that the second user status has changed to on-line, to
• Transport servers are provided with a mechanism for monitoring the connection status of an intended recipient, which advantageously does not involve the message sender's resources. Rather, they can effectively watch the connection status of the intended recipient, and when it changes such that a peer-to-peer communications then becomes possible, the message sender can be notified.
• This also supports data messaging without any storage of the data message on- route at a potentially insecure location.
• the fourth aspect of the present invention is also realised in a method of assisting the establishment of a peer-to-peer data communication, such as an e-mail communication, between a first and second user computers, the method comprising: receiving from the first user computer a request for connection to the second user computer which is locally registered; verifying the current connection status of a connection to the second user computer; storing details of the request as a watch if the current connection status of the second user computer indicates that a peer-to-peer communication cannot at present be established with the second user computer; and sending a message to the first user computer indicating the on-line status of the second user computer if in response to the verifying step the status of the second user computer changes to indicate that a peer-to-peer communication can now be established with the second user computer; wherein the verifying step comprises periodically checking and updating the current connection status to the second user computer, and when an update indicates that the second user status has changed to on-line, checking for the existence of a corresponding watch and if found activating the response means to
• a fifth aspect of the present invention addresses the issue of overcoming the problems associated with NATs and firewalls such that the peer-to-peer communications can be supported.
• This aspect of the present invention resides in the appreciation that the mapping function of a NAT can be determined by sending the implementation of a series of communications (investigations) of the capability of the intended recipient including the determination of the actual local address of the recipient even though this is not normally visible on the remote communications side of the NAT.
• These investigations include use of a communications control channel and the important function of the intended recipient sending its local address as data within a message through the NAT such that the translation function of the NAT can be extrapolated.
• Other investigations include the ability to provide the results of investigations on the potential intended recipient.
• mapping function of the NAT is that this can then be used to send the NAT an appropriately addressed communication which will be mapped back by the NAT to the desired single recipient location.
• the NAT is completely unaware that its mapping function has been determined and as a result direct peer-to-peer communications can be supported.
• a method of establishing a secure peer-to-peer data communication channel such as an e-mail communication channel, between a first and second user computers over a data communications network where at least the first user computer has its communications handled by a first Network Address Translator (NAT), the method comprising: requesting a direct connection over an established Transmission Control Protocol/Internet Protocol (TCP/IP) communications link between the first user computer and a transport server through the first NAT; establishing a first User Datagram Protocol (UDP) port at the transport server; reporting the address of the first UDP port to the first user computer via the TCP/IP communications link; opening a second UDP port at the first user computer; transmitting data packets from the second UDP port via the first NAT to the first UDP port such that the transport server is
• TCP/IP Transmission Control Protocol/Internet Protocol
• UDP User Datagram Protocol
• This fifth aspect of the present invention provides a simple workable solution which enables NAT traversal for peer-to-peer communications, even in the case when one of the NATs is asymmetric.
• the fifth aspect of the present invention also extends to a transport server for assisting in establishing a secure peer-to-peer data communication channel, such as an e-mail communication channel, between a first and second user computers over a data communications network where at least the first user computer has its communications handled by a first Network Address Translator (NAT), the method comprising: request receiving means for receiving a request for a direct connection over an established Transmission Control Protocol/Internet Protocol (TCP/IP) communications link between the first user computer and the transport server through the first NAT; establishing means for establishing a first User Datagram Protocol (UDP) port at the transport server; reporting means for reporting the address of the first UDP port to the first user computer via the TCP/IP communications link; data packet receiving means for receiving data packets transmitted from a second UDP port set up at the first user computer via the first NAT to the first UDP port, the transport server being arranged to determine the first NAT address of the second UDP port; obtaining means for obtaining at the transport server a third UDP port address of the
• a method of establishing a secure pseudo peer-to-peer data communication channel such as an e-mail communication channel, between a first and second user computers over a data communications network where both the user computers have their communications handled by respective first and second asymmetric Network Address Translators (NATs)
• the method comprising: creating a Transmission Control Protocol/Internet Protocol (TCP/IP) communications link from each of the user computers to a transport server through the respective first and second asymmetric NATs; establishing a first and a second User Datagram Protocol (UDP) port at the transport server in response to receiving a request for a direct connection, the request being received over the TCP/IP communications link between the first user computer and a transport server through the first NAT; reporting the addresses of the first and second UDP ports to the first and second user computers respectively via their respective TCP/IP communications links; opening a third UDP port at the first user computer and a fourth UDP port at the second user computer; transmitting data packets
• TCP/IP Transmission Control Protocol/Internet Protocol
• the pseudo peer-to-peer communication is provided by the ability of the present aspect of the invention to 'bounce' out messages off a local transport server that acts as a trusted intermediary.
• the possible reduction in security of such an indirect communications channel is minimised by ensuring that the bounced out packets are forwarded by the transport server acting as the trusted intermediary with minimal analysis, and certainly no storage.
• the present aspect of the present invention is arranged to implement a true peer-to-peer communication in one direction and to bounce off a local transport server in the other direction. This variation is worth doing because it minimises the reduction in security. For example, in the case of e-mail transmission, it is advantageous to arrange that the e-mail is sent directly, and that the acknowledgements are bounced back.
• This sixth aspect of the present invention also extends to a transport server for assisting in establishing a secure pseudo peer-to-peer data communication channel, such as an e-mail communication channel, between a first and second user computers over a data communications network where both the user computers have their communications handled by respective first and second asymmetric Network Address Translators (NATs), the transport server comprising: creating means for creating a Transmission Control Protocol/Internet Protocol (TCP/IP) communications link from each of the user computers to a transport server through the respective first and second asymmetric NATs; establishing means for establishing a first and a second User Datagram Protocol (UDP) port at the transport server in response to receiving a request for a direct connection, the request being received over the TCP/IP communications link between the first user computer and a transport server through the first NAT; reporting means for reporting the addresses of the first and second UDP ports to the first and second user computers respectively via their respective TCP/IP communications links; receiving means for receiving data packets transmitted from a third UDP port set up at the first
• a method of connecting a user computer to a hierarchical connection network of transport servers for assisting in establishing a peer-to-peer communication between a sender computer and an intended recipient computer over a data communications network comprising: receiving information describing the current loading of each of a plurality of peer transport servers at the same hierarchical level in the connection network as a local transport server; receiving a request to connect a local user computer to the local transport server; comparing the current loading of the local server with each of the peer servers; sending a response to the local user computer indicating that it should connect to the peer server having the lowest loading if the loading of the local transport server is significantly greater that the loading of any one of the peer servers; and accepting the request to connect if the loading of the local transport server is not significantly greater that the loading of any one of the peer servers, and updating the current loading of the local transport server.
• This aspect of the present invention addresses the problem of load balancing in a communications network.
• a method of joining a node to a network of authenticated communications servers set up to be used in establishing a peer-to-peer data communications between user computers registered with the communications servers comprising: using a user identity and password received from an authentication server to authenticate the node to the authentication server; being notified of the identity of a selected communications server to which the node needs to connect to join the network; requesting selected communications server and node specific data from the authentication server for a connection to the selected communications server; receiving selected communications server and node specific data and a shared encryption key shared by the node and the selected communications server; transmitting the selected communications server and node specific data and global data encrypted by the shared encryption key to the selected communications server, such that the selected communications server has the tools by which to authenticate the node to the network and thereby join to the same without the need to seek verification from the authentication server.
• This aspect of the present invention provides a very secure way of implementing an authentication procedure for a new node wishing to join a network. This is particularly important in the context of a messaging source wishing to join a peer-to-peer communications facilitating network where access to the network bestows privileges upon the messaging source, for example being allowed to communicate freely with other members of the communications network.
• a method of connecting a first hierarchical realm of interconnected transport server nodes to a second hierarchical realm of interconnected transport server nodes comprising: providing a local authenticating server within each realm, the authenticating server being connected to a primary node at the highest level of the respective hierarchical realm and being arranged to control the authentication issues related to all servers within the realm; registering the primary node of the first hierarchical realm to the authenticating server of the second hierarchical realm; authenticating the primary node of the first hierarchical realm to the authenticating server of the second hierarchical realm; being notified of the identity of a lowermost node server to which the primary node of the first hierarchical realm needs to connect to join the hierarchical realms together; receiving shared data and shared encryption keys for both of the lowermost node server of the second hierarchical realm and the primary node of the first hierarchical realm; using the receiving shared data and shared encryption keys to authenticate the primary node of the first hierarchical
• This aspect of the present invention is advantageous in that it enables corporations with their own communications networks (realms) to join together without loss of security as a result. Also the integrity of each realm remains intact as only the permissions in higher realms need to be modified in the above simple manner in order to effect the joining together of what could be very significant sized existing networks. This means that communications between people in completely different organisations becomes possible in a very secure way using peer-to-peer technology.
• Figure 1 is a schematic block diagram of a system according to an exemplary embodiment of the present invention
• Figure 2 is a schematic diagram showing an example of how the system of Figure 1 can be used to enable peer-to-peer communications between two users, Bob and Alice;
• Figure 3 is a block diagram showing a method of overall operation of the personal e-mail server of Figure 1;
• Figure 4 is a block diagram of a ConnectfromClient subroutine of the method of Figure 3;
• Figure 5 is a block diagram of a MessageReceive subroutine of the method of Figure 3;
• Figure 6 is a block diagram of a Message WaitingToSend subroutine of the method of Figure 3;
• Figure 7 is a flow diagram showing the interaction between the Transport server mechanisms and the mails server for determining the unique address of an intended recipient
• Figure 8 is a schematic diagram illustrating the different uses of the system by different entities
• Figures 9a to 9f are a series of schematic block diagrams illustrating the investigations which are carried out by the TSMs in determining the unique IP address for the intended recipient;
• Figures 9g to 9i show how the investigations carried out in Figures 9a to 9f can be applied in the case of symmetric NATs and also in the case of asymmetric NATs;
• Figure 10 is a schematic block diagram showing the overall functional tree architecture of a second embodiment of the present invention.
• Figure 11 is a schematic block diagram showing the hierarchical nature of the administration level of the tree architecture of Figure 10;
• Figure 12 is a schematic block diagram showing the hierarchical nature of the transport server layer of the tree architecture of Figure 10;
• Figure 13 is a schematic block diagram showing the functional elements of a generic transport server of the transport server layer of Figure 12;
• Figure 14 is a flow diagram showing the process of load balancing new connections to the administration layer of Figure 10;
• Figure 15 is a flow diagram showing the first stage of establishing a peer-to-peer connection using the network of the second embodiment of Figure 10;
• Figure 16 is a flow diagram showing the second stage of establishing a peer-to-peer connection using the network of the second embodiment of Figure 10;
• Figure 17 is a schematic block diagram showing how the principles of the Kerberos technique are applied in a third embodiment of the present invention.
• Figure 18 is a block flow diagram showing the main steps of the third embodiment in seeking a connection to a network
• Figure 19 is a schematic block diagram showing the details of the registering with a central data server and thereafter how a peer-to-peer communications is supported from a security angle by the network;
• Figure 20a is a schematic block diagram of a parent node within the hierarchical network of Figure 19;
• Figure 20b is a schematic block diagram of a child node within the hierarchical network of Figure 19.
• Figure 21 is a schematic block diagram showing how cross-realm linking is achieved in effecting a peer-to-peer call between user computers X and Y.
• a system 10 embodying the present invention is shown. This embodiment is described with reference to the presently preferred e-mail communication. However, it is to be appreciated that any form of electronic communication transmission can be used such as Voice over IP (VoIP) or instant messaging for example. Furthermore, even though the present embodiment is described in relation to communications over a Wide Area Network such as the Internet, the invention can be implemented over a Local Area Network, or could even be carried out via mobile telecommunications.
• VoIP Voice over IP
• instant messaging for example.
• the present embodiment is described in relation to communications over a Wide Area Network such as the Internet, the invention can be implemented over a Local Area Network, or could even be carried out via mobile telecommunications.
• the system 10 comprises two personal computers (PCs) 12, 14 provided at different locations.
• the first PC is a local PC 12 and the second PC is a remote PC 14 and the system 10 supports peer-to-peer communications between these two computers 12, 14.
• Each PC 12, 14 is identical in its communication function and therefore it is only necessary to describe one in detail.
• Each PC 12, 14 is connected to the Internet 16 in this embodiment, via a respective Internet gateway 18, 20.
• the Internet gateway 18 at the local PC 12 also includes a NAT 22 as the local PC 12 is provided as one of a plurality of local PCs 12 on a LAN 24 which all utilise the local Internet gateway 18.
• the remote PC 14 is also provided on a LAN 26 but in this case no NAT is provided and the remote PC 14 has a unique IP address.
• a data server 28 is also provided which is connected to the Internet 16.
• the data server 28 has a local database 30 of usernames 32 and IP addresses 34 which it manages.
• the local database 30 also stores the connection status 36 of the registered users.
• These usernames 32 and addresses 34 have been provided to the database 30, including those of the local and remote PCs 12, 14, by way of a registration procedure which is not described in detail herein as such procedures are commonly known.
• the data server 28 does not take active part in peer-to-peer communications between registered PCs, such as the local and remote PCs 12, 14. It does, however, update all the PCs 12, 14 which are registered with the latest address information 34 and the status 36 of that address, namely whether it is on-line or off-line.
• a plurality of transport server mechanisms (TSMs) 40 are provided which are all connected to the Internet 16. These TSMs 40 facilitate the establishment of the correct address 34 for a peer-to-peer communication between the local and remote PCs 12, 14.
• Each TSM 40 has associated with it a local store 42 of information for storing addressing information regarding each of the possible addresses of the registered PCs 12, 14. More specifically, these local stores comprise a list of PC identities 44 and a corresponding list of IP addresses 46.
• a direct IP address 46 is provided in the cases when the TSM 40 is itself responsible for addressing of a given PC. Otherwise, in cases where it is not responsible, an IP address (or other suitable identification) of the responsible TSM 40 is provided.
• the operation of the TSMs 40 particularly with reference to NAT traversal, is described in detail later.
• Each of the local and remote PCs 12, 14 includes a mail client 50 such as Microsoft OutlookTM, which is connected via TCP/IP to a personal mail server 52.
• the mail server 52 has its own local data store 54 provided and is also connected to a network interface 56.
• the mail server 52 is provided in the downloaded software and is installed by the user in order to utilise the peer-to-peer communications protocol.
• the mail server 52 stores the network address of the data server 28 as it needs to contact it to let it know when it goes on-line. All peer-to-peer communications are routed through the personal mail server 52 in a transparent manner such that the operation of the mail client 50 is unaffected.
• the network interface 56 and the internet gateways 18,20 used in the present embodiment are entirely conventional and need no further explanation herein.
• the personal e-mail server 52 is downloaded and installed locally on the user's PC 12, 14.
• the personal e-mail server 52 operatively connects to the e-mail client 50 and the network interface 56, both of which are already provided on the PC 12, 14. All e-mail communications to and from the e- mail client 50 are via the personal e-mail server 52.
• the user In sending a message, the user creates the e-mail and then sends it to the personal e-mail server 52. If the intended recipient is on-line, as indicated in the current information stored regarding the status of the intended recipient, then the e-mail message is sent directly to the intended recipient's PC 14. Otherwise, the e-mail message is stored in a queue until the intended recipient's PC 14 comes on-line as would be indicated by the receipt of an updated on-line status message from the data server 28.
• the actual current IP address 34 of the intended recipient is determined by the TSMs 40. This process is described in detail later. However, on confirmation of the present IP address 34 of the intended recipient, the peer-to-peer communication of the e-mail message is carried out.
• the process 60 commences with Alice's personal e-mail server 52 sending 66 a message to the data server 28 that she has come on- line and indicating 68 that she wants to send a message to Bob 64.
• the data server 28 replies 69 with Bob's current address details.
• Alice's personal e-mail server 52 uses this information to address the message, encrypt it 70 and store it 72 locally for sending to Bob when he goes on-line.
• the data server 28 sends 76 a message out to all users to indicate that Bob 64 has come on-line.
• This message is received by Alice's personal e-mail server 52 and the stored message can then be sent 78 directly to Bob 64.
• Bob's personal e-mail server 52 stores it 80.
• Bob's e-mail client 50 checks 82 for incoming messages (get message), then the message is decrypted 84 and sent 86 to the e-mail client 50 for Bob 64 to read.
• the operation 90 of the personal e-mail server 52 is now described with reference to Figure 3.
• the operation 90 commences with the start up 92 of the server 52, which leads to a connection being made 94 to the data server (DS) 28.
• the address of the data server 28 is already known to the mail server 52 and is stored in the local memory 54.
• the data server 28 provides the location addresses of several TSMs 40, one of which must be available for the system 10 to work.
• the mail server 52 then tries to establish 96 a connection with a TSM 40. As part of this, a check 98 is carried out to see if the TSM 40 is on-line. If a TSM 40 is not on-line and a connection cannot be made, then the mail server 52 is considered to be off-line 100.
• the process 90 can continue with a subsequent reconnection 102 to the Internet 16 and return to the connection to the DS step 94 described above.
• the TSM 40 is on-line 104, one of five different options (states) become available. Firstly, there is an option if the PC 12, 14 is shut down 106 for the process 90 to end 108. Secondly, the mail server 52 can be forced to log out 110, thereby taking the process 90 to the off-line condition 100 as mentioned above. Thirdly, if there is an attempt from the mail client 50 to connect 112 to the mail server 52, then the credentials of the mail client 50 are checked 114 against pre-stored information and if acceptable, a connection from the client can be made 116 (as is described in greater detail later with reference to Figure 4). If the client credentials are not verified, then the connection is refused 118 and the mail server 52 either goes back 120 into an on-line state or is forced off-line 122 and has to connect 102 to the Internet 16 and start the process 90 again.
• a further option (state) is for the mail server 52 to have received 124 a message and for it to be provided to the mail client 52 for presentation to the user. This process 124 is described later in detail with reference to Figure 5.
• the last option (state) available once the mail server is on-line relates to the sending of messages.
• a check 126 is made to determine if there are messages waiting to be sent. If there are no messages to be sent 128, the process 90 ends and the mail server 52 returns to the on-line state 104. If there are messages to be sent, the Message WaitingToSend process 130, as described in greater detail later with reference to Figure 6, is then executed. Following the end of this latter process 130, the mail server 52 returns to the on-line state 104.
• the process 116 commences with an SMPT connection request being received 140 from the mail client 52 (for example MS OutlookTM).
• the process 116 determines, for security purposes, whether the mail client 52 is authorised 142. If they are not, then the authorisation fails 144 and a message is sent 146 to the mail client 52 to notify the user. Otherwise, the authorisation succeeds 148 and the e-mail message from the mail client 50 is received 150 by the mail server 52.
• a check 152 is carried out to determine if there are any more messages to be sent and if so, the transfer process 150, 152 is repeated. When there are no further messages 154 to be received, the mail server 52 disconnects 156 from the mail client 50.
• PKI Public Key Infrastructure
• the encrypted message is then passed onto the Message WaitingToSend process 130, which is described later with reference to Figure 6.
• the mail server 52 In order to receive an e-mail message the mail server 52 does not have to be logged-in but it does have to be connected to the Internet 16. On receipt 180 of an e-mail message, the user is notified 182 of the message and this can be carried out by the generation of a Notify Recipient pop ⁇ up window 184 for example.
• the received e-mail message is stored in memory 54 pending a 'get' (retrieval) from the mail client. The storage can be to the computer's hard disk but for the most secure solution, the received message is stored in RAM until it is retrieved. Whilst it is waiting 186, if for some reason the mail server 52 has to be closed 188, the undelivered message is stored 190 in semi-permanent memory (typically the hard disk) and the process 124 ends 192.
• the process 124 checks 196 to determine whether the mail client 50 is authorised. If it is not, the client authorisation fails 198, resulting a failure 200 of the mail client 50 get procedure. This in turn is notified 202 to the recipient user and to Amteus (which is the authority overseeing the operation of the whole system and with whom the users are registered).
• the mail client 50 is authorised 204, two actions are performed in parallel.
• the private key of the recipient which is stored locally, is retrieved 206 and the undelivered e-mail message is retrieved 208. Then an attempt 210 to decrypt the message is carried out using the retrieved private key. If the decryption is unsuccessful 212, then the sender is notified 214. This is achieved by the mail server 52 sending an e-mail back to the sender stating that there is a delivery failure. Then the process 124 continues as if the earlier client authorisation failed 198, namely with a failure 200 of the mail client 'get' procedure. This in turn is notified 202 to the recipient user and to Amteus.
• the decrypted e-mail message is forwarded to the mail client for presentation to the user, namely the 'getby' the mail client is successful 218.
• the message received process 124 then checks 220 to see if there are any further messages to be delivered. If there are no further messages 222, the message received process 124 ends 192. If there are further messages to be delivered 224, then the process loops back 226 to the stage where the client authorisation is successful 204 and continues as has been described previously.
• the destination status is checked 242 to determine whether the destination is off-line. If it is off-line 244, then the message cannot be sent and the encrypted message is simply stored 246 in the message-waiting queue for a later attempt at transmission. If however, the destination is on-line, then the encrypted message is retrieved 248 from the queue (either in RAM or from the hard disk) and it is sent 250 directly to the intended recipient as a peer-to- peer communication.
• the details of how the accurate addressing of the e-mail message is carried out and how the message is sent are outlined in Figure 7 and are described later.
• a send error state 256 is entered where a procedure for determination of the type of error follows. This state 256 is also reached at the start of the message waiting to send process 130 if the mail server 52 is stopped 258 for some reason. In this send error state 256, Amteus are notified 260, in parallel with determination of the type of error.
• a check 262 is made to determine whether the error was due to the destination being off-line. This could occur if there has just been a change in status of the intended recipient. If the destination was off-line 244, then the encrypted message is stored 246 for later transmission. This ends this pass of the message waiting to send process 130, though not the process 130 in itself as that e-mail message will still be in the queue waiting to be sent.
• a check 266 is carried out to determine whether it was a permanent or temporary failure.
• a permanent failure 268 for example if the user no longer exists, or the e-mail is too big
• the mail server receives 270 a bounce back message saying that the message was undeliverable. If however, the error is due to a temporary failure 272 (due for example to a connection fault), then the encrypted e-mail message is stored 242 back in the queue and this pass of the message waiting to send process 130 ends.
• the local copy of the e-mail is deleted 276 for security purposes.
• a notification of the successful transmission is sent 260 to Amteus and a check 278 is made to determine if there are any more e-mail messages in the queue waiting to be sent. If there are, then the process 130 repeats returning to the checking 232 of the status of the destination (intended recipient) for that e-mail message and continuing as has been described above. Otherwise, there are no more messages to be processed 280 and this pass of the message waiting to send process 130 ends.
• the TSMs are continually carrying out their address investigation process such that at any time when delivery of an e-mail message to an intended recipient is required, they are in possession of the most up-to-date current view of the address information for that intended recipient.
• Their investigations are carried out using a modified UDP (User Datagram Protocol) and comprise experiments, which help to establish the actual direct IP network address of that user. These experiments enable NAT traversal and are described in greater detail later with reference to Figures 9a to 9i.
• the process 274 of determination and communication of the recipient's current IP address to the sender commences with the sender being sent 290 a list of TSMs from a master TSM 40, which holds the list.
• the mail server 52 attempts 292 to contact the first of the TSMs 40 on the list and check 294 if it is successful. If it is not successful 296, then the next TSM 40 on the list is retrieved and another attempt 292 is made to connect. This process continues until one connection is successful 298.
• the selected TSM notifies 300 all the other TSMs 40 that he has the connection for this mail server 52.
• This connection may be made on the basis of which TSM 40 is the most convenient to use with regard to load balancing.
• the sender mail server 52 then communicates 302 to the connected TSM 40 that it wishes to connect to the intended recipient mail server 52.
• the intended recipient is identified by way of user ID. It is the task of the TSM 40 to determine the IP address for that intended recipient mail server 52.
• the selected TSM 40 checks 304 its addressing list (stored locally) to see if it has a direct connection to the intended recipient mail server 52. If it does have a direct connection, namely it knows the unique address for the recipient mail server 52, then this is passed 306 onto the sender mail server 52.
• This address is determined using techniques described later with reference to Figures 9a to 9i. If it does not have the unique address itself, then it at least has the address of the TSM 40, which does have the address. Accordingly in this case, the selected TSM 40 relays 308 the enquiry onto the correct TSM 40 such that it can look up the address and pass this back 306 to the sender mail server 52.
• the sender mail server 52 Once the sender mail server 52 has received the unique direct IP address of the intended recipient mail server 52, it connects 310 directly to the recipient mail server 52 and sends 312 the e-mail message using standard Internet protocol. Namely, the e-mail message is sent in the same way that conventional IP communications are sent on the Internet 16, by dividing the message into packets each with their own header and transmitting these packets to be routed by any appropriate route to the recipient where they are assembled together again for presentation to the intended recipient.
• Figure 8 is a schematic diagram showing the different activities of a user 320, its mail client 50,322 and an administrator 324.
• the different activities are grouped into related functions as has been shown on the diagram. More specifically, the use 320 can carry out three different groups of related functions, namely set up activity 326, payment activities 328, and file related activities 330.
• the mail client 50, 322 can carry out a single group of mail server-related activities 332.
• the administrator 324 can carry out a single group of user- related activities 334.
• the functions that make up each of these groups are illustrated in Figure 8 and will be clear to the skilled addressee, and therefore no further explanation is provided herein.
• Figures 9a to 9f show and explain the six stages of actions, which are carried out by the TSMs 40 in determining the unique IP address for the intended recipient. More specifically, an initial state is shown in Figure 9a, where Client A 350 has made a TCP/IP connection via NAT A 352 to Server S 354, and similarly, Client B 356 has also established a TCP/IP connection via NAT B 358 to Server S 354. At this stage, labelled Stage 1, Client A 350 desires to established a peer-to-peer connection with Client B 356.
• Step 2A shown in Figure 9b Client A 350 makes a peer-to-peer request to Server S 354 via Nat A 352.
• the Server S 354 opens up a UDP port 360 on IP address Sl port S 1 362.
• Client A 350 then opens its own UDP port 366 at address A:a 368. This port address 368 is translated by NAT A 352 to A 1 Ia 1 370.
• a UDP communications channel 372 is set up between Client A 350 and the Server S 354.
• Server S 354 opens up a second UDP port 376 on IP address S2: S 2 378 such that it can establish a UDP channel with Client B 356 in a similar manner to that described in relation to Figure 9c. Then Server S 354 reports the address (S 2 :s 2 ) 378 of the UDP port 376 to Client B 356 via the already established TCP/IP communications medium 364. Client B 350 then opens its own UDP port 380 at address B:b 382. This port address 382 is translated by NAT B 358 to B ⁇ b 1 384. However, a UDP communications channel 386 is established between Client B 356 and the Server S 354 as can be seen in Figure 9e.
• Server S 354 is able to forward packets received from network translated port address A 1 Ia 1 370 to B 1 Ib 1 384 and from network translated port address B 1 Ib 1 384 to A 1 Ia 1 370. This enables Client A 350 and Client B 356 believe that they have a direct UDP connection with each other.
• Figure 9f shows Stage 5 in the process and establishes the general case for peer-to-peer communications.
• Server S 354 firstly informs Client A 350 that Client B 356 is talking on network translated port address B 1 Ib 1 384. Also Server S 354 informs Client B 356 that Client A 350 is talking on network translated port address A 1 Ia 1 370. Therefore the ability for Client A 350 and Client B 356 to talk directly is established as they each have the other's network translated address 370, 384.
• communications may be over a first UDP channel 388 between UDP port A:a 366 and address B 1 Ib 1 384 or both port addresses B 1 Ib 1 384 and SIiS 1 362.
• communications may be over a second UDP channel 390 between UDP port Bib 380 and address A 1 Ia 1 370 or both port addresses A 1 Ia 1 370 and S2iS 2 378.
• Figure 9g shows how the general case of Figure 5 is applied for the case when both NATs are symmetric. More specifically, in Stage 6A if NAT A 352 is a symmetric NAT then Client B will receive UDP packets from network translated port address A 1 Ia 1 370. Similarly if NAT B 358 is a symmetric NAT then Client A will receive UDP packets from network translated port address B 1 Ib 1 384. When such UDP packet traffic is detected, Server S is informed and it breaks the UDP connections 372 between NAT A and its first port 362 and between NAT B and its second port 376, which is the situation illustrated in Figure 9g. Also following this, TCP connections 364 between Clients A and B to Server S 354 could be dropped, but this is dependent on the applications running on Clients A and B.
• Figure 9h shows how the solution of Figure 9g does not work when one of the NATs is asymmetric. More specifically, If NAT B 358 is asymmetric then UDP packet traffic from port address B:b 382 directed at network translated address A ⁇ a 1 370 will appear to come from B 2 :b 2 392 but will still be received by Client A over a second UDP channel 390. However, UDP packet traffic from network translated address A ⁇ a 1 370 to network translated address B ⁇ b 1 384 will be blocked by NAT B 358 as that port is no longer being used for communications to Client B 356.
• Figure 9i shows the solution provided by the present embodiment of how to deal with one of the NATs being an asymmetric NAT. More specifically, in Stage 6B Client A sees UDP packet traffic coming from network translated address B 2 :b 2 392 rather than network translated address B ⁇ b 1 384. Accordingly, NAT A 352 switches its UDP traffic output intended for network translated address B ⁇ b 1 384 to network translated address B 2 :b 2 392. NAT A 352 can do this because NAT B 358 has used this address to write to network translated address A 1 Ia 1 370 of NAT A 352 and so IP passes. In this way bi-directional communications are established even when an asymmetric NAT is present.
• the secure communications system 400 is distributed and can be complex due to its size.
• its overall architecture can be considered to be a hierarchical tree 402 as is set out in Figure 10.
• the system 400 appears at three logical levels: the system administration level 404, the transport server level 406 and the end point level 408.
• the boxes shown in Figure 10 represent logical functions, which may actually be realised in a plurality of very different ways.
• the top level 404 of the tree 402 is concerned with Administration functions of the system 400.
• This level 404 holds a database 410 (see Figure 12) of all computers permitted to use the system 400, and controls whether or not individual peer-to-peer communications are allowed to be set up.
• Security is also controlled from this administration level 404. Individual communications connections at lower levels must be authorised from the Administration level 404; once so authorised, lower administration levels may negotiate encryption keys for example between themselves prior to creating additional connections.
• the administration level 404 is also informed, to a customisable level of detail, of any additional connections that are created and may also record events that occur at lower levels. These events include at the very minimum, each attempted access to the network.
• the administration level 404 is also capable of producing management reports concerning the operation of the network, which is very useful for control and management of the system 400.
• end points 412 At the lowest level 408 are the "end points"412. These include “softphones” (software for handling VOIP calls) and localised e-mail servers. However, the end points 412 can also include other forms of data communications tools. The end points 412 are the key components that get installed on users' computers to enable access to the system 400 and the secure method of corrununicating provided thereby. Each end point 412 is inherently secure as it is provided at the user's location, therefore storage of communications at end points 412 does not compromise the security of the data communications in any way.
• the end points 412 and administrative layer 404 only communicate via the transport server 414 that comprise the transport layer 406. This provides the advantages of simplicity and scalability.
• the administration level 404 in the example shown in Figure 11, has a hierarchical tree ⁇ like structure, which enables efficient management of control of the system 400.
• the distributed nature of the administration layer is evident from Figure 11 and it can be seen that at the top of the hierarchy is the Amteus Global administration node 416, which runs from a single central location.
• the client administration nodes 418 are provided, with only one shown in the Figure 11 example, which may be implemented on, for example, the computers of corporate or governmental bodies (not shown) which may wish to control communications between its registered users.
• the client at the client-specified location runs the single client administration node 418 shown in Figure 11.
• the next layer in the hierarchy is the layer 420 of regional administration nodes 422 for a given client of which three are shown in Figure 11. These regional administration nodes 422 connect to the end points 412 (EP 1 to EP 3) via the distributed transport layer 406 (only represented as a dotted line). This lowest level of administration 420 is geographically based and is important for several issues including load balancing which is described in detail later. Similarly, in this example, a further end point EP4 412 has its administration functions implemented directly at the Amteus Global administration node 416 via the transport layer 406.
• Each user represented by an end point 412, is registered at one administration node 416, 418, 422, typically its regional administration node 422. This registration is communicated up the hierarchical administration tree and as a result the registration details are held at all administration nodes 418, 416 at higher levels.
• the registration information that is stored at these administration nodes 418, 416 includes all details about the user, as collected during a registration procedure, together with the current operating state of the end point 412. Any decisions as to whether to permit peer-to-peer communication between end points 412 are taken at the lowest level in the hierarchy at which both users registration details are available. Any resulting changes in operating state of these end points 412 are then passed to administration nodes at higher levels.
• the EP (End Point) 412 is typically a telephone and/or e-mail user.
• EPl 412 is based in the Client's London Office. His details are stored in the London regional administration node 422, and at all administration nodes 416, 418 at higher levels.
• EP2 and EP3 412 are based in the Client's Athens Office. Their details are stored at the Athens regional administration node 422, and at all administration nodes 416, 418 at higher levels.
• EP4 412 is a private Amteus subscriber, known only to Amteus and as such he is registered only with the Amteus Global Admin node 416.
• Athens regional administration node 422 knows both end point users 412 and the request may therefore be handled locally in Athens by the Athens Admin node 422. Details may be sent to administration nodes 416, 418 at higher levels for information purposes, but these higher- level nodes 416, 518 are not involved in the setting up the desired communication channel.
• EPl 412 wishes to communicate with EP2 412, he will make his request to his local Administration node 422 in London.
• This London regional administration node 422 knows nothing about EP2 412, so it changes the status of EPl as being in a Call Setup and passes the request up the hierarchical tree to the Client Administration node 418.
• the client administration node 418 knows about both parties to the call, so it can handle the desired call setup. It knows whether EP2 416 is busy as it has the latest status information to hand, but there is a slight chance that its view on this is out-of-date and this is catered for as is described later. If the client administration node 418 believes EP2 416 to be busy, it so informs the London regional administration node 422, which in turn informs EPl 412. The request for set up thus ends in failure.
• the client administration node 418 also marks the EPl status as being in a 'Call Setup', and passes the request down to the Athens regional administration node 422.
• the Athens regional administration node 422 may know that EP2 416 is now busy (i.e., the status at the client administration node 422 was actually out of date). In this case, it returns a "busy", failure code to the client administration node 418, which then cancels the request for setting up the communications channel as in the previous case.
• Athens regional administration node 422 forwards the call request to EP2 412.
• EP2 412 decides whether or not to accept the call and passes the appropriate response back along the route to EPl 412 in reverse.
• EPl 412 wishes to communicate with EP4 412, a similar process occurs.
• the initial request is passed all the way up to the Amteus global administration node 416 via its regional administration node 422 and the client node 418.
• the Amteus global administration node 416 then communicates directly with EP4 412 to set up the connection.
• the term 'locally' as used above is intended to mean a geographical locality to the server. However, in the strictest sense, this term simply means that there is a relatively direct connection between the server and the end point and that the end point is registered with that server, which makes that end point then local to that server.
• the transport level 406 of the hierarchy 402 of Figure 10 is made up of transport servers 414 connected to each other in a hierarchical tree structure.
• Each transport server 414 is responsible for facilitating the transportation of a communication from one location (end point) 412 to another without storing the message en-route.
• a main transport server 424 is provided and this is connected to the Amteus global Administration (Database) Server 410, which tops the administration hierarchy.
• a hot standby transport server 426 is provided as a back up to the main transport server 424 in case of failure.
• Three regional transport servers 1, 2 and 3 428 are shown connected in the next level 430 of the hierarchy to the main transport server 424. These regional transport servers 428 in turn are connected with respective End Points 1.1, 1.2, 2.1 and 3.1 412.
• the above-described transport level 406 represents a dynamic structure, which is not predefined. Rather, rules are defined and provided for connecting together the transport servers 414 dynamically to form the network. Furthermore, the administration level 404 which is functionally shown as a different layer in Figure 10, is actually incorporated into the hierarchical network of transport servers 406 and is utilised in the setting up of a peer- to-peer communication. Finally, the network has a built-in security overlay, which improves network security.
• the overlay is implemented in this embodiment as a functional rule which applies to all nodes of the network, namely: a node is not permitted to communicate to an end point 412 unless that end point 412 is known to that node. When the node does not know personally of the identity of the desired end point 412, it passes up the request for communication further up the hierarchical tree.
• each transport server 414 has a client link (uplink) 430 to a higher- level transport server 414 and/or a client link 432 to an Administration (database) server 410 (both have been shown for convenience in Figure 13).
• the uplink 430 is to the Administration database server 410, whereas otherwise it is to a higher-level transport server 414.
• At the bottom of the transport server tree are end-points 412 as described above in relation to Figure 12.
• Each transport server 414 also has a downlink 434: a server connection, by which lower-level transport servers 414 and end-points 412 may initiate connections to the server 414.
• the uplink 430 on each transport server 414 is a TCP/IP client; and the downlink 434 is a TCP/IP server.
• Each transport server 414 runs in an environment not subject to network address translation. This means that each transport server 414 has its own public IP address 436, which may be dynamically allocated as well as its own transport server ID 438. These are stored in its local database 440together with list 442 of end point IDs that are connected to that particular transport server 414, the status 444 of the connections to each of those end points 412 and the permissions 446 associated with each of the end points 414.
• a database server 448 is provided to access and update this information as required.
• the lists of end point (user) information stored in the database 440 are arranged as described below.
• Two lists are provided one in the database 440 which is a compilation of the IDs of locally registered users who are currently on-line 444 and the other which is a compilation 450 of the IDs of those locally registered end points 412 which have watches recorded against them.
• a watch is recorded when a particular end point 412 is connected but not available for communication, for example when it is busy.
• the watch monitors the status of the destination end point 412 and when it becomes available for communication, a trigger mechanism (not shown) in the watch triggers off a notification process.
• the notification process sends out messages to all of the end points 412 and transport servers 414 that have recorded an interest in watching the change of status of the connection to the desired destination end point. Furthermore, the change of state is notified up to higher levels in the hierarchical network.
• the database 440 also stores a set of public encryption keys 451 for the end points 412. These as will be described in greater detail later are used to decrypt encrypted messages sent from different end points 412.
• the transport server 414 also comprises a location module 452 for determining the current geographical location of the transport server 414 and a heartbeat monitor 454 for checking its connections to different but adjacent transport servers 414 in the hierarchical network.
• the transport servers 414 of the network must be authorised by the Administration System 404 (shown in Figure 11) exactly as must end points. As mentioned previously, each transport server 414 has its own entries in the database 440, with permissions to act as transport servers 414, and have User IDs.
• Transport servers 414 are "location aware" by the functioning of the location module 452. This can be achieved in a plurality of different ways. For example, one simple way is for the location module 452 to be windows based, where the current time zone of the system on which the location module is running can be determined.
• a heartbeat is a signal which contains update information regarding the transport server's registered connections (loading) and which confirms the existence of a communications link between the parent and child transport servers 414.
• the purpose of the heartbeat monitor 454 is to control load balancing of the system 400. More specifically, the heartbeat information contains a count (usage count) of the number of end points 412 currently registered directly at the originating (regional) transport server 414.
• each (parent) transport server 414 responds with a message giving the list of the IP addresses and ports of the downlink, plus the usage count, of all the other transport servers at the same level.
• the main transport server 424 receives a heartbeat from transport server 414, it replies with each of the regional transport server 1 and 3's 412 respective addresses and usage counts.
• a flow diagram is shown of the load balancing procedure 460 of this aspect of the present embodiment.
• a new client end point 412 or lower-level transport server 4114 seeks to connect at to a transport server 414
• a request is received at Step 464 by the transport server 414, the request containing the new client's heartbeat signal.
• the transport server 414 retrieves at Step 466 its own stored usage count U 1 and the usage counts U 2 U 3 U 4 of other transport servers 414 at the same level and geographically at least as close (for example in the same time zone).
• the transport server compares at Steps 468 and 470 its usage count U 1 against those U 2 U 3 U 4 of the other proximate transport servers 414 at the same hierarchical level. If its usage count U 1 is much higher than the usage counts U 2 U 3 U 4 any of its peers 414, a reply is sent back at Step 472 to the new client telling him to connect to the transport server 414, which currently has the lowest usage count, to effect the peer-to-peer communication. The connection with the current transport server 414 is then terminated at Step 474 and the load balancing procedure 460 ends at Step 476.
• the request for connection is accepted at Step 478, the client's user count is read at Step 480 and the local usage count of the transport server 414 is incremented at step 482 by the amount of the client's user count. Subsequently the load balancing procedure ends.
• the receiving transport server 414 may then examine whether there are any lower-level transport servers 414, which are geographically close to the new connection and are better capable of handling it. This is considered advantageous, as it would aid overall system performance if users were connected at the extremities of the transport server tree where possible. This is because the majority of peer-to-peer communications are voice over IP traffic, which is heavy on bandwidth and also usually local. Therefore by keeping this main traffic at a local transport server level the whole hierarchical system 406 does not become burdened with this traffic, which would otherwise slow the system 400 down considerably.
• Any transport server 414 accepting a new connection informs its new child user of its own parent transport server's address. It also informs its parent transport server 414 of the new user's connection. The parent transport server 414 thereafter considers the new user to be connected to it.
• a new user 412 is able to initiate send messages to its transport server 414 in the following categories:
• the transport server 414 passes such requests to its parent transport server 414, after tagging them with its own transport address/port 438.
• the message contains the UserID for the source and destination end points.
• the transport server 414 looks up the UserID in the list of currently connected users (end points). This list is created by looking at list 442 of users registered with that transport server 414 and looking at their respective statuses 444. If it finds the user, then the message is forwarded to that user, possibly via one or more lower-level transport servers 414.
• the message is passed to the transport server's parent transport server 414. If the top of the transport server tree 424 is reached and the destination is not found, failure is reported back to the source. This process is effectively sending a reply message back from the top-of-tree user ID to the original message source.
• the process of checking the data stored at each transport server's parent 414 relies on the fact that each registration of a user is passed back up the tree to the parent of each node such that the top of the tree has a picture of all the connections. Accordingly, if the desired user is not found at the top of the tree 424, they cannot have registered with the network.
• an end point 412 loses a connection to its direct parent transport server 414, it attempts to connect to its grandparent transport server 414.
• the grandparent transport server 414 may then find an alternative connection at the original level.
• each end point 412 has a single client TCP/IP connection to their transport server parent 414. This connection is used for access to both higher-level transport servers 414 and to administration servers 410, 404.
• Each end point 412 provides a communication interface (not shown) with the user to facilitate VoIP communications, for example.
• each end point 412 also uses a so-called "Multimedia” engine (not shown).
• This multimedia engine comprises microphones, speakers or headphones, WaveFile players and recorders and video players and recorders.
• the multimedia engine also incorporates a digital signal-processing module, allowing audio to be translated between different wave formats, attenuated, amplified and mixed.
• the multimedia engine is not described further as the functions of the multimedia engine are commonplace within the art and the skilled addressee will need no further explanation to construct such an engine.
• the method 500 is essentially a two-stage process where in the first stage (described in Figure 15), it is established whether it is possible to set up the desired peer-to-peer connection between the specified end points 412, and in the second stage (described in Figure 16) a peer-to-peer connection is set up between the source 412 and the desired destination 412.
• a peer-to-peer connection Once a peer-to-peer connection has been established, direct two-way communications between the source 412 and destination 412 are possible in a secure manner, using standard Internet communications protocols; in this embodiment over a dedicated UDP channel 372.
• the following description relates to the first and second stages described above.
• P2P connections may be set up between end points 412. These connections are then, in the current embodiment, used to transmit audio and email data but other forms of communications can also be used.
• the need for a new P2P connection first arises at an end point 412 - for example, when an end user decides to make a VoIP telephone call to another end user.
• the originator of the connection knows only the network address of the desired destination (the target user's ID); he does not know the status of the target user, namely whether the user is online, busy etc. (He may know that the target user was recently online etc, through his address book, but will never be absolutely certain of the current state).
• the method 500 of implementing the first stage commences with the source user 412 sending at Step 502 a request to its transport server 414, of the form "I (User S) wish to communicate with User D".
• the transport server 414 looks in its list 442, 444 of connected users 412 and checks at Step 506 to see if User D is found. If it finds User D 412 connected, it checks at Step 508 whether the user D 412 is available.
• Step 510 If not, it returns at Step 510 a "Failed - Busy" response and preferably sets up at Step 512 a watch against User D; finally User S waits pre-determined time period at Step 514 and then retries to connect again and/or simply awaits notification of the watch being triggered at the current transport server in response to a change in User D's availability status.
• the transport server 414 changes at Step 516 the status of both User S and User D to be in a "Call Setup in progress" state.
• the transport server 414 then forwards at Step 518 the request to User D possibly via other transport servers 414 at lower levels than the current transport server 414.
• User D is considered at Step 520 to have been found and connected to and the process 500 continues as is described below in relation to Figure 16.
• User D subsequently has a change of status in that he becomes available for communication, this is notified to User D's local transport server 414 and the watch set up there for User S is triggered. User S is then notified at Step 514 of the availability of User D and the first stage can commence once again as has been described above. Alternatively, or in combination, User S can wait at Step 514 a predetermined amount of time before restarting the process 500 from scratch as has been indicated in Figure 15.
• a check at Step 522 is carried out to determine if a parent Transport server 414 exists. If a parent does exist, the request is forwarded at Step 524 to the parent TS 414. Thereafter, the patent transport server 414 is considered at Step 526 to be the current transport server and the process continues with the current transport server 414 checking at Step 504 its list of registered end users 412. If there is no parent TS 414 as determined by the check carried out at Step 522, the transport server sends at Step 528 a reply back to the end point indicating a failure to connect and the process ends at Step 530.
• a call request arriving at a transport server 414 from a higher-level transport server 414 is handled in exactly the same way except that, in the event that the user is not connected, a failure is returned rather than forwarding the request back from whence it came.
• a transport server 414 On receiving at Step 536 a RINGING 1 message, a transport server 414 first constructs also at Step 536 a UDP (User Datagram Protocol) channel 372. It then constructs at Step 540 a RINGING2 message, containing the external IP address and port number of the UDP channel, and sends also at Step 540 this message both to the end point User D and to the call originator end point User S.
• the RINGING2 message also contains the User ID of the transport server 414, which received the RINGINGl message, since this will be used to set up the peer-to-peer connection.
• a transport server 414 never sends a RINGINGl message. Hence a RINGINGl message arriving at a transport server is always considered to have come directly from an end point 412.
• an end point 412 When an end point 412 receives at Step 542 a RINGING2 message, it checks at Step 544 that it is in Call Setup state. If it is not, then it resets at Step 546 all the named parties to the call and the process 500 ends at Step 530. Otherwise, each end point 412 sets up at Step 548 a UDP channel and starts to send at Step 550 messages periodically to the port specified in the RINGING2 message. This will be the transport server 414 closest to the Callee. Unless there is some general network failure, most of these messages should arrive correctly.
• the transport server 414 closest to User D receives the first UDP message from each end point 412, it also extracts at Step 552 the (possibly translated - described later) network address and port number of the end point's UDP channel 372.
• the transport server 414 is then able to send (not shown) replies down each end point's UDP channel 372, which includes the UDP network address and port number of the other end point's UDP channel, and these should arrive even at each end point if their firewalls are present. (Normal firewall action at the end points should allow this since the end points initially wrote to the transport server.)
• the transport server 414 Once the transport server 414 has received packets from both end points, it knows how their UDP ports are addressed externally.
• the transport server 414 then sends at Step 554 a TALKDIRECT message to each end point 412 telling it of the other end point's address.
• a TALKDIRECT message to each end point 412 telling it of the other end point's address.
• NATs 352, 358 are broadly categorised into two classes of translation function: Symmetric and Asymmetric. Symmetric NATs use the same Internet- side address and port combination regardless of the destination of a packet; Asymmetric NATs use different Internet-side address/port combinations for each destination. Whilst it is not exactly clear what the reasoning for this is, it is considered that it is based on a belief that it is wise to keep out data packets from unknown sources.
• a bit of thought regarding the necessity for these NATs indicates that: 1. The recipient can see from whom each packet comes, and can easily reject those from an unknown source if required without the requirement for a NAT. 2. The IP address and port in an Internet packet are easy to fake. Such draconian action by NATs is unlikely to deter a reasonably competent hacker for very many minutes.
• Firewalls can also cause a problem when seeking to establish a peer-to-peer communication.
• the normal firewall action is to impose a "don't speak until you're spoken to" rule. IfA and B want to talk to each other, either A or B has to speak first. The other can then reply. But, if A speaks first, and B is behind a firewall, B will not see the packet until it has written to A.
• Firewalls/NATs commonly implement a uPnP (universal Plug 'n' Play) interface by which their actions may be interrogated and, subject to security constraints, amended.
• the present embodiment includes a uPnP interface (not shown) which has been implemented hi the transport servers 414.
• the present embodiment is arranged to 'bounce' out messages off a local transport server 414 that acts as a trusted intermediary. This mitigates issues of unknown sender as the local transport server 414 will always be known to the local asymmetric NAT 352, 358 such that even the most severe rules at a firewall, for example, will not prevent such indirect pseudo peer-to-peer communications. Furthermore, the possible reduction in security of such an indirect communications channel is minimised by ensuring that the bounced out packets are forwarded by the transport server 414 acting as the trusted intermediary with minimal analysis, and certainly no storage.
• the present system is arranged to implement a true peer-to-peer communication in one direction and to bounce off a local transport server 414 in the other direction.
• This variation is worth doing because it minimises the reduction in security.
• it is advantageous to arrange that the e-mail is sent directly, and that the acknowledgements are bounced back.
• the local transport server 414 knows the addresses of the UDP ports of both end points 412, as has been described above in relation to Figure 16, it sends the TALKDIRECT message to each, giving them the other end point's address.
• the end points 412 attempt to communicate directly, and also set up a timer (not shown). If packets are received directly, the transport server 414 is told the connection is talking, and the timer is stopped and used no further.
• TALKTHROUGH a TALKTHROUGH message is sent to the transport server 414 and thence to the other end point 412, indicating that further communications are to be sent directly to the local server 414 for the intended destination end point 412. Messages are thereafter "bounced" off the transport server 414 that is local to the desired end point 412.
• the system 10 commences setting up the peer-to-peer connection before the callee accepts the call. If the call is not accepted, then the peer-to-peer connection will be closed immediately.
• the present system 10 starts the process only when the call is accepted; where the timeout / TALKTHROUGH method is implemented, this can lead to an awkward delay in establishing the voice link, for example. It is also the case that the majority of calls / e- mails, where a user is logged in, will be accepted.
• a third embodiment of the present invention is now described with reference to Figures 17 to 20.
• the third embodiment is very similar to the second embodiment except for the issues relating to security. More specifically, the third embodiment substitutes the permissions 446 stored at each node with a more robust security system as described below.
• the third embodiment attenuates this cycle by building in security from the beginning. Attackers can never be eliminated from the system 10 entirely, but there is enough effective security built in to prevent their presence from undermining the availability of the system 10 to registered users. It is to be appreciated that designing a system that completely eliminates attackers would actually result in bankruptcy for the designers.
• Requirement 1 NODEs must be authenticated to the system 10.
• Requirement 2 Communication over NODE to TS links must be confidential.
• Requirement 3 CLIENTS must be authenticated to each other (mutual authentication)
• Requirement 4 Communication over CLIENT to CLIENT connections must be confidential.
• Meeting Security Requirements 1 & 2 Much of the terminology that follows is taken from the RFC 1510, the Kerberos authentication system. Kerberos is an authentication mechanism that is used to verify user or host identity, it is also the preferred authentication method for services in Microsoft Windows Server 2003. The Kerberos authentication protocol provides a mechanism for mutual authentication between a client and a server, or between one server and another, before a network connection is opened between them.
• the protocol assumes that initial transactions between clients and servers take place on an insecure communications network
• an insecure environment could well be exemplified by the Internet, where an attacker can easily pose as either a client or a server, and can readily eavesdrop on or tamper with communications between legitimate clients and servers.
• the Kerberos technique relies heavily on an authentication technique involving shared secrets.
• the basic concept is quite simple: If a secret is known by only two people, then either person can verify the identity of the other by confirming that the other person knows the secret.
• the password is kept secret by using secret key cryptography. Rather than sharing a password, communication partners share a cryptographic key, and they use knowledge of this key to verify one another's identity.
• the shared key must be symmetric i.e. a single key must be capable of both encryption and decryption.
• One party proves knowledge of the key by encrypting a piece of information, the other by decrypting it.
• authenticators can work as follows.
• a simple protocol that uses secret key authentication begins when someone is outside a communications door and wants entry. To gain access, this person presents an authenticator in the form of a piece of information encrypted in the secret key. The information in the authenticator must be different each time the protocol is executed; otherwise an old authenticator could be reused by anyone who happens to overhear the communication.
• the person guarding the door decrypts it and knows from what is inside whether decryption was successful. If it was successful, the doorkeeper knows that the person presenting the authenticator has the correct key. Only two people have the correct key; the doorkeeper is one of them, so the person who presented the authenticator must be the other.
• the same protocol can be executed in reverse, with a slight difference.
• the doorkeeper can extract part of the information from the original authenticator, encrypt it in a new authenticator, and then give the new authenticator to the person waiting outside the door.
• the person outside the door can then decrypt the doorkeeper's authenticator and compare the result with the original. If there is a match, the person outside the door will know that the doorkeeper was able to decrypt the original, so he must have the correct key.
• FIG. 17 The basic principle of how the Kerberous technique is used in the present embodiment is illustrated in Figure 17.
• a Server 602 a Client 604 and a Key Distribution Centre 606 are provided.
• the Client 604 wishes to connect to the Server 602 and first applies to the Key Distribution Centre (KDC) 606 to obtain a ticket for establishing a valid connection to the Server 602.
• KDC Key Distribution Centre
• the ticket is used effectively to authenticate the Client 604 to the Server 602, who is already authenticated to the system 600.
• TS Transport Server 414.
• NODE Combined CLIENT and TS. Sometimes referred to as simply a CLIENT 5 or simply a TS, in which case the other function is available but diminished in terms of the particular role being described for the NODE 608.
• AS Authentication Server 610. 2005/002509
• TGS Ticket Granting Server 612
• REALM 614 Community of NODEs 608 sharing an AS 610.
• an Authentication Server 610 associated with a particular REALM 614 containing a number of NODEs 608 is available.
• the AS 610 stores the equivalent of a ⁇ USERNAME, PASSWORD ⁇ doublet for each registered NODE 608 in its local database 616.
• the client at NODE_A 608 wishing to connect to the network has used an Internet browser 618 to connect to a web server 620 of the KDC 610 to register and thereby obtained a username "UserA" 622 and a Password "pwdA"624.
• NODE_A NODE 608 with username A.
• TGT_A Ticket Granting Ticket 626 for NODE_A.
• S_A Session Key 628 between AS 610 and NODE_A 608.
• K_AB Shared Key 630 between NODE_A and NODE_B.
• TICKET_AB Ticket 632 to allow NODE_A to gain access to NODE_B.
• ⁇ X ⁇ K_Y Value X encrypted by the key, K_Y.
• NODE_A 608 connects to a TS 414 and sends an AS_REQ 634 message to the AS 610 for the REALM 614 that NODE_A 608 belongs to (typically the message passes up through the hierarchical network until a TS 414 is found with a connection to the AS 610).
• the AS 610 generates a session key S_A 628 and replies with an AS_RESP message 636 containing TGT_A 626 and S_A 628 both encrypted with the pwdA 624.
• the AS 610 may reply with an encrypted TIMESTAMP (not shown) for additional authentication security.
• NTP Network Time Protocol
• NODEs 608 are synchronised to the AS's time when they authenticate to the system 600.
• NODEs 608 have to associate the AS-supplied TIMESTAMP with their current Win32 tick count, and calculate their new current time whenever they need to generate their own TIMESTAMP value.
• NODE A 608 Once NODE A 608 has been authenticated, it is assumed that it is informed by the network of the name of the TS 414 that it must now "link" to in order to join the network (i.e. be able to make and receive VoIP calls), and that the target TS 414 is called NODE_B 608. Where timestamping has been used, the sequence is as follows:
• NODE_B 608 For NODE_B 608 to allow NODE_A 608 to link to it, NODE_B must decrypt TICKET_AB 632 to extract K_AB 630 and then decrypt ⁇ TIMESTAMP ⁇ K_AB to be able to verify the TIMESTAMP. Assuming this is successful then NODE_B 608 replies with an AP_RESP message 644 containing ⁇ TIMESTAMP + 1 ⁇ K_AB which allows NODE_A 608 to authenticate NODE_B 608.
• NODE_A 608 is now “linked” into the network via NODE_B 608 (in reality the CLIENT 604 in NODE_A is being served by the TS 414 in NODE_B 608).
• the above implementation is based on an adapted sub-set of the Kerberos authentication system, which re-uses the basic protocols, messages and data structures but differs in functionality which makes the new authentication technique of the present embodiment effective for use in the context of peer-to-peer communications.
• DH_PK_A Diffie-Hellman Public Key 646 for CLIENT_A.
• DH_SK_A Diffie-Hellman Private Key 648 for CLIENT_A.
• DH_PK_B Diffie-Hellman Public Key 650 for CLIENT_B.
• DH_SK_B Diffie-Hellman Private Key 652 for CLIENT_B.
• K_AC Shared Key 654 between NODE_A and NODE_C.
• CLIENT A 604 generates a Diffie-Hellman (DH) key pair and sends a message to CLIENT_C 604 that includes the value of DH_PK_A 646. The message is sent via the chain of authenticated links 656 that connects them (as part of a communications channel setup protocol). 2. On receipt of the message, CLIENT-C 604 assumes that it must have been sent by an authenticated source (although CLIENT_C 604 is not in a position to formally authenticate that source, hence the implied weaker label for this form of authentication, "authentication-by-induction"). 3.
• DH Diffie-Hellman
• CLIENT-C 604 generates a Diffie-Hellman (DH) key pair and sends a message to CLIENT_A 604 that includes the value of DH_PK_B 650. The message is sent back to CLIENT_A 604 via the same (although it could be via a possibly different) chain of authenticated links 656. 4. Both CLIENT-A 604 and CLIENT_C 604 are now in a position to independently calculate the shared key K_AC 654. Any party intercepting DH_PK_A 646 or DH_PK_B 650 will not be in a position to calculate K AC 654 and impersonate CLIENT_A 604 or CLIENT_C 604. 5. CLIENT_A 604 and CLIENT_C 604 use K_AC 654 to generate bulk encryption keys for the Advanced Encryption System (AES), or equivalent, allowing confidential communications.
• AES Advanced Encryption System
• the second possible type of authentication is provided externally to the Amteus system 600, but is one with which the Amteus system 600 must interoperate. It is assumed that an externally provided Public Key Infrastructure (PKI) is available and that CLIENTS are Public Key Enabled (PKE). In these circumstances, the above protocol would be extended to an RSA cryptographic algorithm which would digitally sign the messages sent between CLIENT_A 604 and CLIENT_C 604, such that strong authentication would be available (further discussion of PKI is not provided here as it is well understood in the art).
• PKI Public Key Infrastructure
• PKE Public Key Enabled
• the present embodiment uses the less secure but more practical "authentication-by- induction” approach.
• the present embodiment there can be a plurality of REALMS 614 and these are organised in a hierarchical fashion for the administration system 404.
• authentication between NODEs 608 in different REALMS 614 is carried out.
• a NODE 608 is a collection of sub-systems, the relevant sub-set of which is illustrated in Figures 20a and 20b. Connections or links are made to/from a NODE 608. The distinction is made here between a simple connection, which may be ephemeral and does not require NODE-NODE encryption, and a link which is a more permanent arrangement and has an associated encryption key 630, 654.
• Figures 20a and 20b show two NODEs 608 both of which contain identical sub-systems (i.e. they are different instances of the same executable).
• the parent NODE 608 ( Figure 20a) is a primary NODE in that a Data Client (DC) 656 is connected to a Data Server (DS) 612 and the KDC 610 is active.
• the child NODE 608 ( Figure 20b) does not have a DS connection, so the DC 656 and KDC 610 are present but inactive.
• the primary NODE 608 handles by use of its security services 660, all security requests received from its children.
• the CLIENT 604 and TS 414 communicate with the SS 660 using handles (not shown).
• a handle is associated with each connection or link (i.e. each active server stream), whether a CLIENT connection/link 662 to a parent NODE 608 or a TS connection/link 664 from a child NODE 608.
• a CLIENT sub-system will attempt to establish a link 662 to a parent NODE 608 (this is also true for a primary NODE 608, in which case the link is cross-realm - see later).
• the SS 660 is instructed to build security requests for sending to the parent NODE 608 as well as processing security replies received from the parent NODE 608.
• the CLIENT 604 can make calls into the SS 660 in order to encrypt or decrypt link messages.
• the CLIENT 604 receives a security message than an appropriate call is made into the SS 660; if this NODE 608 is not the target of the message then the CLIENT 604 routes the message to the TS 414 for passing further down the hierarchy until chosen destination NODE 608 is reached and the message consumed.
• Child NODEs 608 communicate messages to the TS 414. If the TS 414 identifies a message as a security message, then an appropriate call is made into the SS 660; if the call is unsuccessful or the target is further up the hierarchy, then the TS 414 routes the security message to the CLIENT 604 for passing up to the parent NODE 608.
• KDC 610 is available at a NODE 608, because it is the primary NODE 608, security requests received from children at the TS 414 must be satisfied by this NODE 608 and not propagate higher up.
• the simplest implementation is for CLIENT 604 to assign some states for managing link setup.
• the SS 660 will NOT make callbacks into the CLIENT 604 or TS 414. Tight integration of sub-systems is assumed, such that CLIENT 604 and TS 414 must maintain states for management of security requests and replies.
• a REALM 614 as has been described above is a set of registered users (similar to a Windows Domain), where each user is registered for that REALM 614 (typically via a web server 620) and has an account (not shown) maintained on the DS 612 for that REALM 614.
• a DS (Data Server) 612 holds all the authentication data for a particular REALM 614 and this data does not propagate outside the REALM 614 in which it is created.
• the primary NODE 666 is effectively the security root for a REALM 614 and security requests are not allowed to propagate further up the hierarchy.
• FIG. 20 and 21 show the solution provided by the present embodiment, the primary NODE 666 for REALM A 614 is allowed to link to a parent NODE 670 in the "higher" REALM B 614. This link 672 is possible because an account is set-up in DS B 612 to allow the primary 666 of REALM A 614 to be authenticated to REALM B 614 and the link 672 created.
• Bootstrap sequence instructs the DC (Data Client) 656 to log into a local DS 612.
• Bootstrap sequence calls procedure SecurityService::Initialise().
• the KDC 610 generates its key and establishes a handshake with the DC 656.
• User enters ⁇ username, password ⁇ to allow the CLIENT 604 to link to a parent NODE 670 (in another REALM 614).
• the CLIENT 604 gets a handle for the new connection to the parent node 656 via procedure SecurityService: :CreateSecurityContext(). 5.
• the CLIENT 604 calls procedure SecurityService: :BuildAsReq() to build an AS_REQ message 634 and then sends the AS_REQ message 634 to the parent NODE 670. 6.
• the CLIENT 604 receives an AS_REP message 636 and passes it to procedure SecurityService: :ProcessAsRep().
• the CLIENT 604 calls procedure SecurityService: :BuildTgsReq() with the ID of the NODE it wishes to connect to, so the SS (Security Service) 660 can build an appropriate TGS_REQ message 638.
• the TGS_REQ message 638 is sent to the parent NODE 670. 8.
• the CLIENT 604 receives a TGS_REP message 640 and passes it to procedure SecurityService: :ProcessTgsRepO- 9. At this point the CLIENT 604 will either be promoting the existing connection to link status or reconnecting to a different parent NODE 670 (but in either case, the target NODE must be the NODE that was named in the procedure BuildTgsReq() call).
• CLIENT 604 calls procedure SecurityService: :BuildApReq() to construct an AP_REQ message 642, which the CLIENT 604 then sends to the parent NODE 670. 10.
• CLIENT 604 receives an AP_REP message 644 and passes it to procedure SecurityService:: ProcessApRes().
• the SS 660 should have the necessary security context to support encrypt/decrypt operations on the link 672 to the parent NODE 670.
• Non-PrimarvNODE Startup 1. NODE 608 is not supplied with DS login arguments so the bootstrap sequence does not instruct DC 656 to log into a local DS 612. 2. The bootstrap sequence calls procedure SecurityService: :Initialise(). KDC 610 is not supplied with parameters for generating a key and DC 656 indicates that it is not connected to a DS 612. 3. The user enters ⁇ username, password ⁇ to allow the CLIENT 604 to link to a parent NODE in the same REALM 614 (the link may or may not be to a primary NODE 666). 4. The CLIENT 604 gets a handle for the new connection to the parent node via procedure SecurityService: :CreateSecurityContext(). 5.
• the CLIENT 604 calls procedure SecurityService: :BuildAsReq() to build an AS_REQ message 634 and sends the AS_REQ message 634 to the parent NODE. 6.
• the CLIENT 604 receives an AS_REP message 636 and passes it to procedure SecurityService: :ProcessAsRep().
• the CLIENT 604 calls procedure SecurityService: :BuildTgsReq() with the ID of the NODE 608 it wishes to connect to, so the SS 660 can build an appropriate TGS_REQ message 638.
• the TGS REQ message 638 is sent to the parent NODE.
• the CLIENT 604 receives an TGS_REP message 640 and passes it to procedure SecurityService: :ProcessTgsRepO- 9.
• CLIENT 604 will either be promoting the existing connection to link status or reconnecting to a different parent NODE (but in either case the target NODE must be the NODE 608 that was named in the procedure BuildTgsReq() call).
• CLIENT calls procedure SecurityService: :BuildApReq() to construct an AP_REQ message 642, which the CLIENT 604 sends to the parent NODE. 10.
• the CLIENT 604 receives an AP_REP message 644 and passes it to procedure SecurityService: :ProcessApRes().
• the SS 660 should have the necessary security context to support encrypt/decrypt operations on the link to the parent NODE.
• Primary NODE Receiving AS REO or TGS REO requests from child NODEs Assume that the primary NODE 666 is initialised and has a KDC 610 that can accept security requests.
• a TS 414 receives an AS_REQ message 634 from a child NODE 668. If the connection/link has a security context then procedure SecurityService: :DecryptLinkData() is called to decrypt the message. 2. The TS 414 passes the AS_REQ message 634 to procedure SecurityService: :ProcessAsReq(). To fulfil the request, the KDC 610 extracts the Username from the AS_REQ message 634 and uses it to request the (hashed) password held in the DS 612 (via the DC 656). 3. If successful, procedure SecurityService: :ProcessAsReq() returns an AS_REP message 636.
• the TS 414 sends the AS_REP message 636 to the child NODE 668 that sent the AS_REQ message 634.
• a primary NODE 666 receives a TGS_REQ message 638 then the same procedure is followed (except that now the (hashed) password for the NODE 608 to be linked to is requested from the DS 612).
• Non-Primary NODE Receiving AS REQ or TGS REO from child NODEs 1.
• the TS 414 receives the AS_REQ message 634 from a child NODE 668. If the connection/link has a security context then procedure SecurityService: :DecryptLmkData() is called to decrypt the message 634. 2.
• the TS 414 passes the AS_REQ message 634 to procedure SecurityService: :ProcessAsReq(), which returns a suitable error code to indicate that an active KDC 610 is not available. 3.
• the TS 414 routes the AS_REP message 636 to the CLIENT 604 for passing to the parent NODE 670.
• the TS 414 receives AP_REQ message 642 from a child NODE 668. An existing security context, and therefore link, should not be available on this connection, so it should not be necessary to decrypt the message. 2.
• the TS 414 passes the AP_REQ message 642 to procedure SecurityService: :ProcessApReq(), which uses its local NODE password (and not the KDC 610) to process the message 642 and generate a suitable AP_REP message 644 for returning. If the procedure SecurityService: :ProcessAsReq() call succeeds, then a full security context is now established and the connection to the child NODE 668 is promote to link status. 3.
• the TS 414 returns the AP_REP message 644 to the child NODE 668.
• Primary or Non-Primary NODE Receiving AS REP or TGS REP from a parent NODE If the CLIENT 604 in a primary NODE 666 receives an AS_REP message 636 or a TGS_REP message 640, then the primary NODE 666 must be the source of the original AS_REQ message 634 or the TGS_REQ message 638, this has already been discussed above for start-up cases (there should not be an existing security context).
• a NODE 608 receiving an AS_REP message 636 or the TGS_REP message 640 is not a primary NODE 666, then the requests are routed to the TS 414 for passing down to the appropriate child NODE 668.
• the link 672 down to the child NODE 668 may or may not have a security context (the child NODE 668 may be sending the AS_REQ and TGSJREQ messages 634, 638 up to a higher KDC 610 in order to link to this NODE 608).
• the present invention is not limited to the specific embodiments described above.
• the e-mail message to be sent can be split into multiple parts and each part separately encrypted. Then each part can be sent separately to a respective transport server mechanism. Each part will be routed independently to the destination and can be decrypted and reassembled at the intended recipient.
• the advantage of this is that interception and successful decryption of one e-mail message does not disclose the message. This is a very robust way of improving security of messaging.
• the text of an e-mail can be sampled to obtain one part of the message to be sent, e.g.
• every fifth letter of the e-mail text could be sampled to create one of the five e-mail messages.
• the other e-mail messages would also be sampled at every fifth letter but would each have a different offset from the first e-mail message.
• the present invention is applicable to wireless telecommunications networks (such as networks employing WIFI).
• PDAs Personal Digital Assistants
• mobile telephones could also be used as the source and destination communication devices in this peer-to-peer communications system.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Computer Security & Cryptography (AREA)
• Computer Hardware Design (AREA)
• Computing Systems (AREA)
• General Engineering & Computer Science (AREA)
• Computer And Data Communications (AREA)
• Data Exchanges In Wide-Area Networks (AREA)
• Information Transfer Between Computers (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=32800303

Family Applications (1)

Country Status (8)

Families Citing this family (16)

Family Cites Families (6)

• 2004
  • 2004-06-28 GB GBGB0414415.0A patent/GB0414415D0/en not_active Ceased
• 2005
  • 2005-06-28 KR KR1020077002255A patent/KR20070092196A/ko not_active Ceased
  • 2005-06-28 JP JP2007518679A patent/JP2008508573A/ja active Pending
  • 2005-06-28 CA CA002572027A patent/CA2572027A1/en not_active Abandoned
  • 2005-06-28 CN CNA2005800250716A patent/CN101053239A/zh active Pending
  • 2005-06-28 AU AU2005256849A patent/AU2005256849A1/en not_active Abandoned
  • 2005-06-28 EP EP05755600A patent/EP1769620A2/de not_active Withdrawn
  • 2005-06-28 WO PCT/GB2005/002509 patent/WO2006000802A2/en not_active Ceased

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events