JP2008508573A - Improvements related to secure communications - Google Patents

Abstract

A method of performing secure peer-to-peer data communication such as electronic mail communication between a first remote computer and a second remote computer via a data communication medium will be described. The method includes receiving the address details of each remote computer and the current state of the connection to the data communication medium, generating a data communication at the first remote computer, and the current connection of the second remote computer. The data communication is not memorized only when the state is confirmed and the connection state of the second remote computer indicates that the second remote computer is currently connected to the data communication medium. Directing data communication directly from the first remote computer to the second remote computer.
[Selection] Figure 1

Description

  The present invention relates to improvements relating to secure communications, and more particularly, but not limited to, secure peer-to-peer email and data communications and Voice over IP. Yet another aspect of the present invention is directed to a method for supporting direct peer-to-peer communication even when a network address translator (NAT) is provided to protect a communication network and extend its IP addressing range. The present invention is also applied to realizing a very high level of security in such a communication system and in a network using such a communication system.

  There are various ways of transmitting messages over a communication network when indirect communication is desired. However, there is an inherent problem associated with this form of message transmission because it is inherently insecure in the state that a copy of the message can be stored and read by a hacker. Some of such problems described in WO 03/014955 A1 have been addressed by using peer-to-peer communication. However, the main problem with the previously proposed and used solution is the complexity of setting up such communication. The solution presented in this prior art document is inherently insecure and cumbersome because it still requires the work of a central server to facilitate communication. This makes the entire process cumbersome and vulnerable to security breaches.

  Encryption techniques are known that increase the security of electronic mail stored during a communication process. However, encryption techniques are not completely secure and, therefore, advancements in hacking techniques do not provide an essentially viable alternative.

  NAT is a device used to allow a plurality of computers to share an address space for communication such as connection to the Internet. NAT has the disadvantage that peer-to-peer communication does not function properly behind NAT without a complex mechanism that far exceeds the capabilities of the average PC user. Problems associated with NAT in the context of peer-to-peer communication are described in US patent application 2004/0064584 A1.

  There is a desire to improve the aforementioned system, and more specifically, a more secure system is needed. It is also desirable to provide a system that is easier to manage and more user friendly. In particular, a communication system that does not require a user to log on to a central server to facilitate peer-to-peer communication or a communication system that requires even temporary storage of messages at a node during peer-to-peer communication is desired. Therefore, an ideally “pure” peer-to-peer communication system is needed.

  One aspect of the invention resides in the recognition that the most secure peer-to-peer email communications are, for example, those that do not need to store messages in a non-secure environment, i.e., in a communication path other than the source or destination. In this case, there is only a small possibility that a hacker will read the email when it is being sent. For example, the risk of hacking during transmission can be minimized by encrypting e-mail for transmission using PKI (Public Key Infrastructure).

  More specifically, according to one aspect of the present invention, secure peer-to-peer data communication such as email communication is performed between a first remote computer and a second remote computer via a data communication medium. A method of receiving address details of each remote computer and a current state of connection to a data communication medium, generating a data communication at a first remote computer, and a current state of a second remote computer Only when it is found from the connection state of the second remote computer and the connection state of the second remote computer that the connection is currently made to the data communication medium, the first remote computer does not store the data communication on the way. Transmitting the data communication directly to the two remote computers.

  It should be understood that the term “storage” as used herein refers to storage of a complete message. Such storage will provide the possibility for an unauthorized third party to illegally obtain a complete copy of the message. Communication protocols often include some temporary storage of a portion of a message, such as a message that is divided into packets. Such temporary and partial storage of a portion of a message is acceptable by this aspect of the present invention because it prevents a third party from obtaining a complete copy of the message being sent.

  Thus, the present invention provides a significant improvement over the prior art because there is no non-secure storage of complete data messages on the way from the source to the destination. More precisely, even if the destination is not online, the message is always securely and temporarily stored at the source until the peer establishes a peer-to-peer communication channel, resulting in insecure storage of data messages There is no need to do it.

  The present invention is implemented in a system that has a central repository of usernames and their IP addresses. However, the central repository is not used for the actual peer-to-peer communication itself, but rather serves to update the communication means provided at the sender's location. Users are registered in the central repository and assigned a unique IP address name. The registered user then downloads and installs a personal communication server on his computer that facilitates peer-to-peer communication. When a registered user goes online as determined by using a personal communication server, this is notified to the central repository and the user's status can be changed from offline to online. This change in state can be communicated to all other users via the push mechanism, so that both the recipient and sender should be able to send and receive communications at that moment. And peer-to-peer communication that must be performed with the user just connected.

Further, in the aforementioned system, software components for controlling the message transmission function are downloaded and reside in the client personal computer. As will be described in more detail below, the example of sending an email message includes an email server that cooperates with a local email client such as Microsoft Outlook ^TM to allow the user to contact a central server. It handles the sending and receiving of all data messages without access and actually without user interaction. In other words, the client's personal computer can control the desired peer-to-peer communication, and this process is very easy from the user's perspective.

  Yet another advantage of the present invention is the ability to prevent receipt of spam emails, particularly with respect to sending email messages. When all email addresses are verified by the central database, spam sources can be immediately cut off. Furthermore, unlike conventional e-mail addresses, the present invention does not make it easy to obtain recipient addresses.

  Also, it is understood that the user can be notified instantly of the person who can make a call, that is, when this situation information is pushed to the person who wants to make a call, it is always online, so VOIP can be realized relatively easily. I want. Since the VOIP connection is via the Internet, it is free of charge, so that users can make long-distance and short-distance calls without paying the additional cost of a standard Internet connection fee.

  Therefore, according to the present invention, the user can completely transmit and receive confidential information about work and personal information. Also, when the present invention is used with conventional email, the present invention provides a backup system that provides service continuity in the event of a failure, disaster, physical attack, or cyber attack. Provide to the server.

  The present invention makes it impossible for third parties such as ISPs to collect personal information about senders and other tasks for the purpose of advertising and other purposes from received emails. Further, an additional device such as an expensive e-mail server is not necessary, and the cost of technical support is reduced, so that the cost can be greatly reduced.

As will be described in detail later, the present invention can function more than a firewall and does not require additional configuration. The present invention can be seamlessly combined with existing e-mail applications such as Microsoft Outlook ^™ and Novell Groupwise ^™ .

  When the IP address is the actual IP address of the recipient, peer-to-peer communication with the IP address is relatively easy. However, when NAT is used, the sender cannot uniquely identify the recipient, and peer-to-peer communication becomes difficult because of the security function of the NAT as a firewall. Another aspect of the present invention addresses this particular problem (discussed below).

  This aspect of the present invention is also a communication server, and secure communication such as e-mail communication between a first remote computer including the communication server and a second remote computer via a data communication network. Receiving means for receiving address details and current status of each remote computer's connection to the data communication network, and a message generation module for generating data communication at the first remote computer, From the confirmation module for confirming the current connection state of the second remote computer and the connection state of the second remote computer, it was found that the second remote computer is currently connected to the data communication network. Only when data communication is memorized Also believed to provide a communication server including a transmission module configured to send the Rukoto without first remote computer data communication directly to the second remote computer.

  This aspect of the present invention is also a communication system, which includes a plurality of communication servers as described above and a data server connectable to the plurality of communication servers by a data communication network. The current state of the connection of each communication server is received, collected, stored together with the current network address of each communication server, and at least a portion of this information is forwarded to a plurality of communication servers, so that the communication servers The present invention is also applied to a communication system configured to enable peer-to-peer communication between other communication servers.

  According to a second aspect of the present invention, a communication server configured to assist in establishing peer-to-peer data communication, such as e-mail communication, over a data communication network between a first and second user computer. A server is provided at a given hierarchical level in a server network of a plurality of communication servers, and the communication server is operatively connected to other communication servers at other hierarchical levels in the server network. A connection means for enabling, a registration means for registering a plurality of local user computers in a communication server, and a data store for storing registration details of each registered local user computer, wherein the registration details are stored in each local user computer. Has address information and a data store containing the current state of the connection to the data communication network. The connection means transfers the stored registration details to the next communication server at the next higher hierarchical level of the server network and the registration details of any local user computer of the connected communication server at the lower level in the hierarchical network A communication server configured to receive and store the data is provided.

  The use of a hierarchical network of transmission servers is very advantageous because the message transmission network can operate more efficiently. Specifically, when a large load is placed on a communication network due to a large amount of message transmission traffic with a large payload, the use of a hierarchical communication medium allows a large amount of traffic to be locally transmitted without burdening the entire communication system more than necessary. Can be processed. VoIP message traffic can contain particularly heavy payloads and can use up much of the available bandwidth. By using a hierarchical structure to record addressing details in a decentralized manner, localize traffic to specific parts of the communications network, thereby not affecting the performance characteristics of other parts of the network can do. For example, in VOIP communications where most VOIP calls are between a geographically local source and destination, this has a significant performance advantage.

  A second aspect of the present invention is also a method for assisting in establishing secure peer-to-peer data communication such as e-mail communication between a first and a second user computer via a data communication network. Establishing an operable network connection to a communication server at a given hierarchy level in a server network of communication servers at other hierarchy levels in the server network, and a plurality of local Registering and registering user computers with a communication server and storing registration details of each registered local user computer including address information of each local user computer and the current state of connection to the data communication network. The stage stores the stored registration details in the server network. A method comprising: transferring to a neighboring communication server at a next higher hierarchical level; and receiving and storing registration details of any local user computer of a connected communication server at a lower level in the hierarchical network. Also applies.

  According to a third aspect of the present invention, in order to assist in establishing secure peer-to-peer data communications, such as email communications, between a sender computer and a designated recipient computer over a data communications network. A method of searching for a designated recipient computer of a communication message, wherein the method is implemented in a hierarchical network of communication servers and sends a request for data communication including identification of a designated recipient computer and identification of a sender computer to a local server; Determining whether the designated recipient is known to the local server and, if the designated recipient is known to the local server, retrieving stored details about the designated recipient and sending the details to the sender computer Stage and server network if the designated recipient is not known locally The request is forwarded to the next communication server at the next higher hierarchical level, so that the communication server becomes a local server, and the designated recipient is found or the highest server in the hierarchical network is confirmed. A method is provided that includes the steps of determining, retrieving and repeating the transfer until the end of the process.

  This method of using a hierarchical communication network is advantageous because the procedure for finding the destination address is much faster than the prior art. The reason is that the geographical local address for the source is first checked, and then the remote address higher in the hierarchical network is checked gradually until it is found or reaches the top. . Again, when a large number of communications are actually directed to a local destination, such communications can be found quickly and the potential management burden on the network of communications servers can be reduced.

  This third aspect of the invention is also a method for establishing secure peer-to-peer data communication, such as e-mail communication, over a data communication network between a sender computer and a designated recipient computer, wherein a plurality of communication A method of searching for a designated recipient computer as described above, communicating a current global communication address of the designated recipient computer to the sender computer, and a current global of the sender computer, implemented in a hierarchical server network of servers It also applies to a method comprising communicating a communication address to a designated recipient computer and setting up a peer-to-peer communication channel between the sender computer and the designated recipient computer using the global communication address.

  According to a fourth aspect of the present invention, there is provided a transmission server used for establishing peer-to-peer data communication such as e-mail communication between a first user computer and a second user computer, from the first user computer. Receiving means for receiving a request for connection to the second user computer registered in the transmission server; verification means for verifying a current connection state of the connection to the second user computer; and current connection of the second user computer If the state finds that peer-to-peer communication with the second user computer cannot currently be established, the state of the second user computer changes in response to the data store storing the request details as a watch and the verification means The peer-to-peer communication with the second user computer can now be established. Response means for sending a message indicating the online status of the second user computer to the first user computer, wherein the verification means periodically checks and updates the current connection status to the second user computer. This update is used to check for the presence of the corresponding watch when it is found that the status of the second user has changed to online, and activate the response means and send a message if a watch is found A transmission server is provided.

  The transmission server according to this fourth aspect of the invention comprises a mechanism for monitoring the connection status of the designated recipient, which mechanism advantageously does not include the resource of the message sender. More precisely, the transmission server can effectively monitor the connection status of the designated recipient and can notify the message sender when it changes to enable peer-to-peer communication. This supports data message transmissions that do not store data messages in places that may not be secure.

  A fourth aspect of the invention is also a method for assisting in establishing peer-to-peer data communication, such as email communication, between a first and second user computer, from a first user computer, Receiving a request for a connection to a second user computer registered with the second user computer, verifying a current connection state of the connection to the second user computer, and a second connection state from the current connection state of the second user computer. In response to the step of storing the request details as a watch and the step of verifying if the peer-to-peer communication with the user computer is currently not established, the second user computer changes state, If the second user computer indicates that a peer-to-peer communication with the other user computer is currently established, Sending a message indicating the line status to the first user computer, wherein the step of verifying periodically checks and updates the current connection status to the second user computer, from which the second user When it is found that the status has changed to online, the existence of the corresponding watch is confirmed, and when the watch is found, the response means is activated and a message is transmitted.

  The fifth aspect of the present invention addresses the problem of overcoming problems associated with NATs and firewalls to accommodate peer-to-peer communications. This aspect of the present invention is the implementation of a series of communications (investigations) of the designated recipient's capabilities, including the determination of the recipient's actual local address, even if the actual local address is not always visible to the remote communications side of the NAT. It is recognized that the mapping function of NAT can be determined by transmitting. Such investigations include the use of a communication control channel and the critical function of sending its local address as data in a message via the NAT so that the designated recipient can estimate the NAT's translation capabilities. Other surveys include the ability to provide survey results for potential designated recipients.

  An advantage of effectively identifying the mapping function of the NAT is that it can be used to send properly addressed communications to the NAT that are mapped back to the desired single receive location by the NAT. . The NAT is completely unaware that the mapping function has been specified and, as a result, can support direct peer-to-peer communication.

  An alternative way to overcome the problems associated with NAT and firewalls is to use a TCP / IP link established to the transmission server to help create a UDP communication channel that supports peer-to-peer communication. More specifically, according to the fifth aspect of the present invention, at least communication between the first user computer and the first user computer is processed by the first network address translator (NAT). A method for establishing a secure peer-to-peer data communication channel, such as an email communication channel, over a connected data communication network, the transmission control being established by a first NAT between a first user computer and a transmission server Requesting a direct connection via a protocol / internet protocol (TCP / IP) communication link; establishing a first user diagram protocol (UDP) port at the transmission server; via a TCP / IP communication link Report the address of the first UDP port to the first user computer Opening a second UDP port on the first user computer, and allowing the transmission server to determine the first NAT address of the second UDP port from the second UDP port. Sending a data packet to the first UDP port via the NAT, obtaining a third UDP port address of the second user computer in the transmission server, and between the first and second user computers Informing each of the first and second user computers of each other's user computer's UDP port address so that secure peer-to-peer communication can be established.

  It should be understood that NAT traversal is a major problem when trying to establish peer-to-peer communication. This fifth aspect of the present invention provides a simple and feasible solution that allows for NAT traversal of peer-to-peer communications even if one of the NATs is asymmetric.

  A fifth aspect of the present invention is also a transmission server that assists in establishing a secure peer-to-peer data communication channel, such as an email communication channel, between the first and second user computers via a data communication network. Thus, at least a first user computer communication is processed by a first network address translator (NAT) and established by the first NAT between the first user computer and the transmission server / Internet. A request receiving means for receiving a request for a direct connection via a protocol (TCP / IP) communication link; a means for establishing a first user diagram protocol (UDP) port in a transmission server; and a TCP / IP communication link A first UDP port to the first user computer via A reporting means for reporting an address; and a data packet receiving means for receiving a data packet sent from the second UDP port set in the first user computer to the first UDP port via the first NAT. A data packet receiving means configured so that the transmission server determines a first NAT address of the second UDP port; and an acquisition means for obtaining a third UDP port address of the second user computer at the transmission server; A transmission server having means for notifying each of the first and second user computers of each other's UDP port address so that the first and second user computers can establish secure peer-to-peer communication between them. Also applies.

  The most complex situation involving NAT traversal occurs when a direct peer-to-peer connection cannot simply be achieved due to strict firewall implementation or asymmetric NAT on both sides. This situation can be resolved by establishing “pseudo” peer-to-peer communication across an asymmetric NAT. More particularly, according to a sixth aspect of the present invention, there is provided a method for establishing a secure pseudo peer-to-peer data communication channel, such as an email communication channel, via a data communication network between first and second user computers. Communication between both user computers is processed by first and second asymmetric network address translators (NATs) from each user computer to the transmission server via respective first and second asymmetric NATs. Creating a Transmission Control Protocol / Internet Protocol (TCP / IP) communication link and receiving a direct connection request received via the TCP / IP communication link between the first user computer and the transmission server by the first NAT. When the transmission server receives the first and second user diagram protocols (UD) ) Establishing a port; reporting the addresses of the first and second UDP ports to the first and second user computers, respectively, via respective TCP / IP communication links; and the first user computer Open a third UDP port and open a fourth UDP port to the second user computer, and send a data packet from the third UDP port to the first UDP port via the first NAT, 4 UDP port through the second NAT to the second UDP, whereby the transmission server sends the first NAT address of the third UDP port and the second NAT address of the fourth UDP port. And allowing the data packet received at the first UDP port to pass through the second UDP port to the NAT address of the fourth UDP port. Transfer the data packet received at the second UDP port to the NAT address of the third UDP port via the first UDP port, thereby effectively returning the data packet from the transmission server Establishing a pseudo peer-to-peer communication between the first and second user computers.

  As mentioned above, pseudo-peer-to-peer communication is realized by the ability of this aspect of the invention to “bounce” a message at a local transmission server acting as a trusted intermediary. This alleviates the problem of unknown senders because the local transmission server is always known locally asymmetric, so that even the most stringent rules of the firewall do not prevent such indirect pseudo-peer-to-peer communication. In addition, the potential for such indirect communication channels to be compromised ensures that bounced packets are forwarded with minimal analysis and without storage by a transmission server acting as a trusted intermediary. By minimizing.

  When encountering a ridiculous (extremely strict) interpretation of firewall operation, this aspect of the present invention is configured to provide true peer-to-peer communication in one direction and bounce off at the local transmission server in the other direction. This variant is worth doing in order to minimize security degradation. For example, in the case of e-mail transmission, it is advantageous to send the e-mail directly and return an affirmative response.

  This sixth aspect of the invention also provides a transmission that assists in establishing a secure pseudo peer-to-peer data communication channel, such as an email communication channel, between the first and second user computers via the data communication network. A server, in which communication between both user computers is handled by respective first and second asymmetric network address translators (NATs), and a transmission control protocol / Internet protocol (TCP / IP) communication link is connected to each user. Means for creating from the computer to the transmission server via the respective first and second asymmetric NAT, and between the first user computer and the transmission server via the TCP / IP communication link by the first NAT When the direct connection request is received, the transmission server receives the first and second -Establishing means for establishing a user diagram protocol (UDP) port; and reporting means for reporting the addresses of the first and second UDP ports to the first and second user computers via respective TCP / IP communication links. And sent from the third UDP port set in the first computer to the first UDP port via the first NAT and from the fourth UDP port set in the second user computer to the second A data packet sent to the second UDP via the NAT, whereby the transmission server determines the first NAT address of the third UDP port and the second NAT address of the fourth UDP port Receiving means for enabling the data packet received at the first UDP port to pass through the second UDP port to the fourth U Data packets transferred to the NAT address of the P port and received at the second UDP port are transferred via the first UDP port to the NAT address of the third UDP port, whereby the first and second Pseudo peer-to-peer communication between user computers also applies to a transmission server established by effectively returning data packets from the transmission server.

  According to a seventh aspect of the present invention, a user computer is connected to a hierarchical connection network of transmission servers to assist in establishing peer-to-peer communication over a data communication network between a sender computer and a designated recipient computer. A method of receiving information indicating a current load of each of a plurality of peer forwarding servers at the same hierarchical level as a local transmission server in a connection network, and receiving a request to connect a local user computer to the local transmission server Compare the current load on the local server with each of the peer servers, and connect to the peer server with the lowest load if the load on the local transmission server is significantly greater than the load on any of the peer servers. Response to the local user A method is provided that includes sending to a computer and accepting a connection request and updating the current load on the local transmission server when the load on the local transmission server is not significantly greater than the load on any of the peer servers. .

  This aspect of the present invention addresses the problem of communication network load balancing. By maintaining the current load magnitude of the local server within the transmission server hierarchy, the request to establish a peer-to-peer connection can always be efficiently redistributed. By maintaining balanced communication in terms of load, the network itself becomes efficient and performance degradation is minimized.

  According to an eighth aspect of the present invention, there is a method for joining a node to a network of authenticated communication servers configured to be used when establishing peer-to-peer data communication between user computers registered in a communication server. Using the user identification and password received from the authentication server to cause the authentication server to authenticate the node, and receiving notification of identification of a particular communication server that the node must connect to join the network; Requesting data specific to a specific communication server and node from the authentication server to connect to the specific communication server, data specific to the specific communication server and node, shared by the node and the specific communication server A shared encryption key to be received, data specific to a specific communication server and node, and an encryption key The encrypted global data to a specific communication server, so that the specific communication server authenticates the node to the network and thereby joins the network without requiring verification from the authentication server. And providing a method.

  This aspect of the present invention provides a very secure way to implement authentication procedures for new nodes that wish to join the network. This is a situation where a message source is privileged to gain access to the network by accessing the network, for example to join a network that facilitates peer-to-peer communication where it is allowed to freely communicate with other members of the communication network. Is particularly important.

  According to a ninth aspect of the present invention, there is a method for connecting a first hierarchical realm of interconnected transmission server nodes to a second hierarchical realm of interconnected transmission server nodes. Providing a local authentication server within each realm, where the authentication server is connected to the primary node at the highest level of each hierarchical realm and controls authentication issues associated with all servers in the realm Adjusting the primary node of the first hierarchy realm to the authentication server of the second hierarchy realm, and registering the primary node of the first hierarchy realm to the authentication server of the second hierarchy realm. Authenticating, receiving notification regarding identification of the lowest node server to which the primary node of the first hierarchy realm must connect in order to join the hierarchy realms, and the second hierarchy Receiving the shared data and shared encryption key of both the lowest node server of the LUM and the primary node of the first hierarchy realm, and using the received shared data and shared encryption key, the primary node of the first hierarchy realm Authenticating to the lowest node server of the second tier realm, thereby combining the first and second realms without seeking verification from the authentication server of the second realm. Provided.

  This aspect of the present invention is advantageous in that a company with its own communication network (realm) can eventually participate without loss of security. Also, the integrity of each realm is not compromised because it is only necessary to modify the permissions of the higher realm in the simple manner described above to join what would be an existing network of very large size. This means that communication between people from completely different organizations using peer-to-peer technology can be made very secure.

  Referring to FIG. 1, a system 10 embodying the present invention is shown. This embodiment will be described with respect to presently preferred email communications. However, it should be understood that any form of electronic communication transmission may be used, such as Voice over IP (VoIP) or instant messaging. Further, although the present invention will be described with respect to communication over a wide area network such as the Internet, the present invention can be implemented by a local area network or can be realized by mobile communication.

  The system 10 includes two personal computers (PCs) 12 and 14 provided at different locations. The first PC is the local PC 12, the second PC is the remote PC 14, and the system 10 supports peer-to-peer communication between these two computers 12 and 14. The PCs 12 and 14 have the same communication function, so only one unit needs to be described in detail.

  Each PC 12 and 14 is connected to the Internet 16 via a corresponding Internet gateway 18 and 20 in this embodiment. The Internet gateway 18 in the local PC 12 includes a NAT 22 so that the local PC 12 is provided as one of the plurality of local PCs 12 on the LAN 24 using the local Internet gateway 18. Further, although the remote PC 14 is provided on the LAN 26, in this case, no NAT is provided, and the remote PC 14 has a unique IP address.

  A data server 28 connected to the Internet 16 is also provided. The data server 28 has a local database 30 of a user name 32 and an IP address 34 to be managed. The local database 30 also stores the connection status 36 of registered users. These user names 32 and addresses 34 are provided to the database 30 by a registration procedure that includes those of the local PC 12 and remote PC 14 and is generally known and will not be described in detail herein. It will be appreciated that the data server 28 does not play an active role in peer-to-peer communication between registered PCs, such as the local PC 12 and remote PC 14. However, the data server 28 updates all registered PCs 12, 14 with the latest address information 34 and its address state 36, ie, online or offline.

  A plurality of transmission server mechanisms (TSM) 40 that are all connected to the Internet 16 are provided. These TSMs 40 serve to establish an appropriate address 34 for peer-to-peer communication between the local PC 12 and the remote PC 14. Each TSM 40 is associated with a local storage 42 of information for storing addressing information regarding each possible address of the registered PCs 12 and 14. More specifically, these local storage devices include a list of PC identifications 44 and a list of IP addresses 46 corresponding to the PC identifications 44. In the list of IP addresses 46, the IP address 46 is provided directly if the TSM 40 itself serves to address a given PC. If not, i.e., if the TSM 40 does not play that role, the IP address (or other suitable identification) of the TSM 40 that plays the role is provided. The operation of the TSM 40, particularly the NAT traversal, will be described in detail later.

Each of the local PC 12 and the remote PC 14 includes a mail client 50 such as Microsoft Outlook ^™ connected to the personal mail server 52 by TCP / IP. The mail server 52 has its own local data storage device 54 and is also connected to a network interface 56. The mail server 52 is provided with downloaded software and installed by the user to utilize the peer-to-peer communication protocol. The mail server 52 stores the network address of the data server 28 because it must contact the data server 28 to inform it that it is online. All peer-to-peer communications are routed transparently by the personal mail server 52 so as not to affect the operation of the mail client 50.

  The network interface 56 and Internet gateways 18 and 20 used in this embodiment are entirely conventional and need not be described in further detail herein.

  Next, general operation modes of the system 10 will be described. After the user is registered with the service by providing details to the data server 28, the personal email server 52 is downloaded to the user's PCs 12 and 14 and installed locally. Personal email server 52 is operatively connected to email client 50 and network interface 56, both of which are already provided on PCs 12 and 14. All electronic mail communications with the electronic mail client 50 are performed via the personal electronic mail server 52.

  In sending the message, the user composes an email and then sends it to the personal email server 52. If the designated recipient is online, as indicated by the latest information stored regarding the status of the designated recipient, the e-mail message is sent directly to the designated recipient's PC 14. In other cases, the email message is stored in a queue until the designated recipient's PC 14 comes online and is indicated by receiving the latest online status message from the data server 28.

  Prior to sending the message, the actual current IP address 34 of the designated recipient is determined by the TSM 40. This process will be described in detail later. Once the current IP address 34 of the designated recipient is confirmed, peer-to-peer communication of the email message is performed.

  With reference to FIG. 2, an example of how to perform this process 60 will be described with respect to two users Alice 62 and Bob 64. Process 60 first shows that Alice's personal email server 52 sends 66 a message that she is online to data server 28 and indicates that she wants to send a message to Bob 64 68. Next, the data server 28 returns 69 the current address details of Bob. Alice's personal email server 52 then uses this information to address the message, encrypt 70 the message, and store 72 locally for sending when Bob is online.

  Alice is online (a message indicating that has already been sent to the data server 28 66) and Bob is online (sending a message indicating that to the data server 28 74) a short time later. Sends a message to all users that Bob 64 is online 76. This message can be received 78 by Alice's personal email server 52 and the stored message sent directly to Bob 64 78. Upon receipt of the message, Bob's personal email server 52 stores the message 80. When Bob's email client 50 confirms the input message (acquired message) 82, the message is decrypted 84 and sent to the email client 50 for reading Bob 64 86.

  Next, an actual process executed in each personal mail server 52 will be described with reference to FIGS.

  The operation 90 of the personal e-mail server 52 will now be described with reference to FIG. Operation 90 first activates server 52 92 and is connected 94 to data server (DS) 28. The address of the data server 28 is already known by the mail server 52 and is stored in the local memory 54. Data server 28 provides several TSM 40 location addresses, one of which must be available for system 10 to work on. Next, the mail server 52 attempts to establish a connection with the TSM 40 (96). As part of that, a confirmation is made 98 to see if the TSM 40 is online. If the TSM 40 is not online and cannot be connected, the mail server 52 is considered 100 offline. Subsequently, process 90 can reconnect 102 to the Internet 16 and return the connection to the DS stage 94 described above.

  However, when the TSM 40 is online, any of 104 different options (states) can be used. First, there is an option 108 that terminates the process 90 when the PCs 12 and 14 are shut down 106. Second, the mail server 52 can be forcibly logged out 110, which causes the process 90 to go to the offline state 100 as described above. Third, if the mail client 50 is trying to connect to the mail server 52, the credentials of the mail client 50 are checked 114 against already stored information, and if acceptable, the connection from the client is 116 (as will be described in detail later with reference to FIG. 4). If the client credentials are not verified, the connection is rejected 118 and the mail server 52 must be brought back online 120 or forced offline 122, connected to the Internet 16 102, and the process 90 must be resumed. .

  Yet another option (state) is that the mail server 52 receives the message 124 and provides it to the mail client 52 for presentation to the user. This process 124 will be described in detail later with reference to FIG.

  The last option (status) available after the mail server is online relates to sending messages. A check is made 126 to determine if there are any messages waiting to be sent. If there are no messages to send 128, the process 90 ends and the mail server 52 returns to the online state 104. If there is a message to be transmitted, a MessageWaitingToSend process 130 as described in detail later with reference to FIG. 6 is executed. After this latter process 130 is completed, the mail server 52 returns to the online state 104.

Next, the ConnectionFromClient process 116 will be described with reference to FIG. Process 116 initially receives 140 an SMPT connection request from mail client 52 (eg, MS Outlook ^™ ). Process 116 determines 142 for mail security whether mail client 52 is authorized. If not authorized, authorization fails 144 and a message notifying the user is sent 146 to the mail client 52. Otherwise, authorization is successful 148 and mail server 52 receives 150 an email message from mail client 50. This is a multi-step process in which the message elements are transferred sequentially (eg, sent in the order of “from” address, “to” address, message body). This process is performed until a complete message is received. A check is made 152 to determine if there are more messages to be sent, and if there are, the transfer processes 150, 152 are repeated. If there are no more messages to receive 154, the mail server 52 is disconnected 156 from the mail client 50.

  Prior to processing the received message, a confirmation can be made 158 to determine the transmission permission associated with the mail client 50. If the mail client 50 determines that it does not have a reasonable permission to send to a specific designated recipient 160, the email message is not sent 162. However, if the transmission permission is in place, the destination user information is acquired 164. This stage includes requesting and obtaining data server 28 address information for all registered designated recipients. This data includes the user's public key (not shown) for use in encrypting the user's message. If the address information has been recently received in association with another email message, this information may be held in a cache. Therefore, before searching for the address information from the DS 28, a check (not shown) for checking whether the address information of a specific designated recipient is in the cache can be performed.

  Next, a check 166 is performed to determine whether the designated recipient is a recognized mail user. If the user is not a recognized mail user 168, the mail server 52 notifies the mail client 50 only that the message cannot be sent 170 because the system does not know the address. However, if the designated recipient is recognized as a registered user 172, the email message is previously acquired so that public key infrastructure (PKI) encryption technology can be used for encryption / decryption. 174 is encrypted with the public key of the designated recipient.

  The encrypted message is then passed to the MessageWaitingToSend process 130 described later with respect to FIG.

  Next, the MessageReceived process 124 will be described with reference to FIG. In order to receive e-mail messages, the mail server 52 may not be logged in, but the mail server 52 must be connected to the Internet 16. Upon receipt of the e-mail message 180, the user is notified 182 of the message, which can be performed, for example, by generating a notification reception pop window 184. The received electronic mail message is stored in the storage device 54, and “get” (retrieve) from the mail client is put on hold. The storage device may be a computer hard disk, but in the most secure solution, received messages are stored in RAM until retrieved. While waiting 186, if for some reason the mail server 52 must be shut off 188, the undelivered message is stored 190 in a semi-permanent storage device (generally a hard disk) 190 and the process 124 ends 192.

  When the mail server 52 receives an acquisition request from the mail client 50 194, the process 124 checks 196 to determine whether the mail client 50 is authorized. If not authorized, client authorization fails 198 and, as a result, the acquisition procedure for the mail client 50 fails 200. This is notified 202 to the recipient user and Amteus (who has authority to manage the operation of the entire system and the user is registered).

  When the mail client 50 is permitted 204, two operations are executed in parallel. The recipient's private key stored locally is retrieved 206 and the unsent e-mail message is retrieved 208. Next, an attempt 210 to decrypt the message using the retrieved private key is performed. If the decryption is not successful 212 is sent 214 to the sender. This is realized by the mail server 52 returning an e-mail stating that the sending has failed to the sender. Next, the process 124 continues in the same manner as 198 if the previous client authorization failed, i.e., the mail client "get" procedure 200 fails. This is notified 202 to the recipient user and Amteus.

  On the other hand, if decryption is successful 216, the decrypted email message is forwarded to the mail client for display to the user, ie, “acquired” by the mail client is successful 218. Next, the message receiving process 124 checks 220 if there are more messages to be sent. If there are no more messages 222, the message reception process 124 ends 192. If there are more messages to be sent 224, the process returns to step 204 where the client authentication was successful 226 and continues as previously described.

  Next, the message transmission standby process 130 in FIG. 3 will be described with reference to FIG. When an email message awaiting transmission is in the queue 230, the destination state must be determined 232. A check 234 is made to determine whether the current state of the destination is in the cache. If the current state is in the cache, it is retrieved 236 from the cache. If the current state is not in the cache 238, it is retrieved 240 from the DS 28 and updated with the cache removed.

  The destination status is checked 242 to determine if the destination is offline. If the destination is offline 244, the message cannot be sent and the encrypted message is simply stored 246 in a message waiting queue for later transmission attempts. On the other hand, if the destination is online, the encrypted message is removed from the queue (in RAM or from the hard disk) 248 and the message is sent 250 directly to the designated recipient as peer-to-peer communication. Details of how to correctly address an email message and how to send a message are shown schematically in FIG. 7 and will be described later.

  If the message transmission is confirmed 252 and the transmission fails for some reason 254, a transmission error status 256 is entered and the procedure for determining the error type continues. This state 256 is the beginning of the message transmission waiting process 130 when the mail server 52 is stopped 258 for some reason. In this transmission error state 256, Amteus is notified 260 of the determination of the error type in parallel. A check 262 is made to determine if the error is due to the destination being offline. This can happen if the designated recipient's status has just changed. If the destination is offline 244, the encrypted message is stored 246 for later transmission. As a result, the procedure of the message transmission standby process 130 is ended, but the process 130 itself is not ended, and the electronic mail message is still waiting to be transmitted in the queue.

  If the error is not due to the destination being offline, the error has another cause 264 and a confirmation 266 is made to determine whether the permanent failure is a temporary failure. In the case of a permanent failure 268 (eg, if there are no users or the email is too large), the mail server receives a message 270 that the message could not be sent. However, if the error is due to a temporary failure 272 (eg, due to a bad connection), the encrypted email message is returned to the queue and stored 242, and the procedure of this message transmission standby process 130 ends.

  Returning to the result of sending the e-mail message, if it is confirmed that the message has been sent 274, the local copy of the e-mail is deleted 276 for security. A notification of successful transmission is sent to Amteus 260 and a confirmation 278 is made to determine if there is an email message waiting to be transmitted. If so, the process 130 returns to confirming the destination (designated recipient) status 232 of the email message and repeats continuing as described above. If there is no e-mail message waiting to be sent, there is no other message to be processed 280, and the procedure of this message sending standby process 130 ends.

  Referring now to FIG. 7, the operation and interaction of the TSM will be described, in particular how the TSM establishes the designated recipient addressing required for peer-to-peer communication.

  Initially, the TSM always runs the address lookup process, so that whenever it needs to send an email message to a designated recipient, it will have up-to-date current information about that recipient's address information. I want you to understand that Such studies are performed using an improved UDP (User Diagram Protocol) and include attempts to help establish the user's actual direct IP network address. These attempts allow for NAT traversal and are described in more detail later with reference to FIGS. 9a through 9i.

  In process 274 of determining and sending the receiver's current IP address to the sender, the sender is first sent 290 a list of TSMs from the main TSM 40 that maintains the list. Next, the mail server 52 attempts 292 to contact the first TSM 40 in the list and checks 294 for success. If the contact is not successful 296, the next TSM 40 in the list is retrieved and another attempt 292 is made to connect. This process continues until 298 when one connection is successful.

  After connecting, the particular TSM notifies all other TSMs 40 that this mail server 52 is connected 300. This connection can be made based on which TSM 40 is most convenient to use for load balancing. Next, the sender mail server 52 communicates to the connected TSM 40 that it wants to connect to the designated recipient mail server 52 302. The designated recipient is identified by the user ID. The job of the TSM 40 is to determine the IP address of the designated recipient mail server 52. Next, the selected TSM 40 checks its addressing list (stored locally) 304 to see if it has a direct connection to the designated recipient mail server 52. If there is a direct connection, that is, if the unique address of the recipient mail server 52 is known, the unique address is passed 306 to the sender mail server 52. This address is determined using techniques described below with reference to FIGS. 9a to 9i. If the recipient mail server 52 does not have its own unique address, there is at least the address of the TSM 40 (having an address). Thus, in this case, the selected TSM 40 relays 308 the query to the appropriate TSM 40 so that it can refer to the address and return 306 it to the sender mail server 52.

  The sender mail server 52, after receiving the unique direct IP address of the designated recipient mail server 52, is directly connected 310 to the recipient mail server 52 and sends 312 an email message using standard Internet protocols. . That is, an email message divides the message into packets each with its own header, sends such packets sent by any suitable route to the recipient, and reassembles them for display to the designated recipient there. Thus, conventional IP communications are sent in the same way as they are sent over the Internet 16.

  FIG. 8 is a schematic diagram illustrating various activities of the user 320, its mail clients 50, 322, and the administrator 324. Various activities are grouped into associated functions as shown in the figure. More specifically, the user 320 can perform three different groups of associated functions: a setup activity 326, a payment activity 328, and a file related activity 330. Mail clients 50, 322 may perform a single group of mail server related activities 332. Administrator 324 can perform a single group of user-related activities 334. The functions that make up each such group are shown in FIG. 8 and will be apparent to the skilled subject, and will not be described in further detail here.

  FIGS. 9a to 9f show and describe the six-stage operations performed by the TSM 40 in determining the designated recipient's unique IP address. More specifically, FIG. 9 a shows the initial state, where client A 350 has a TCP / IP connection to server S 354 via NAT A 352, and similarly client B 356 via NAT B 358. A TCP / IP connection is established with the server S354. At this stage, indicated as stage 1, client A 350 desires to establish a peer-to-peer connection with client B 356.

In step 2A shown in FIG. 9b, client A350 makes a peer-to-peer request to server S354 via NAT A352. Upon receiving this request, the server S354 opens the UDP port 360 of the IP address S1 port s ₁ 362. Next, in step 2B, as shown in FIG. 9c, the server S354 reports the address (S ₁ : s ₁ ) 362 of the UDP port 360 to the client A 350 by the already established TCP / IP communication means 364. To do. Client A 350 then opens its own UDP port 366 at address A: a368. This port address 368 is converted to A ₁ : a ₁ 370 by NAT A352. On the other hand, a UDP communication channel 372 is set between the client A 350 and the server S 354.

At stage 3 shown in FIG. 9d, server S354 can establish a UDP channel with client B 356 in the same manner as described with respect to FIG. 9c, and a second UDP port 376 with IP address S ₂ : s ₂ 378. open. Next, the server S354 reports the address (S ₂ : s ₂ ) 378 of the UDP port 376 to the client B 356 through the TCP / IP communication means 364 already established. Client B 350 then opens its own UDP port 380 at address B: b382. This port address 382 is converted to B ₁ : b ₁ 384 by NAT B358. On the other hand, as can be seen in FIG. 9e, a UDP communication channel 386 is established between the client B 356 and the server S354.

Referring to FIG. 9e, stage 4 of the process of establishing a designated recipient's unique IP address is shown, and a method for performing UDP communication between client A and client B will now be described. Client B sends a UDP packet from UDP port 380 having address B: b382 to server UDP port 376 having address S2: s ₂ 378. However, the server S354 knows that these packets are coming from the network translation UDP port address B ₁ : b ₁ 384. Similarly, a UDP packet can be received from client A 350 at server UDP port 360 having address S 1: s ₁ 362.

The server S354 transfers the packet received from the network translation port address A ₁ : a ₁ 370 to B ₁ : b ₁ 384 and the packet received from the network interpretation port address B ₁ : b ₁ 384 to A ₁ : a ₁ 370. can do. As a result, it is possible to believe that the client A 350 and the client B 356 have a direct UDP connection with each other.

FIG. 9f shows stage 5 of the process and establishes the general case of peer-to-peer communication. In this case, server S354 first notifies client A350 that client B356 is talking on network translation port address B ₁ : b ₁ 384. In addition, the server S354 notifies the client B356 that the client A350 is talking on the network conversion port address A ₁ : a ₁ 370. Thus, the ability of client A 350 and client B 356 to speak directly is established when each client has a network translation address 370, 384 of each other. However, depending on the application (not shown) running on client A 350, the communication is between UDP port A: a 366 and address B ₁ : b ₁ 384 or both port address B ₁ : b ₁ 384 and S 1: s ₁ 362. Or a first UDP channel 388 between them. Similarly, depending on the application (not shown) running on client B 356, the communication may be UDP port B: b380 and address A ₁ : a ₁ 370 or port address A ₁ : a ₁ 370 and S2: s ₂ 378. It may be via a second UDP channel 390 between them.

FIG. 9g shows how the general case of FIG. 5 is applied in the case where both NATs are symmetric. More specifically, in step 6A, if NAT A 352 is a symmetric NAT, client B receives a UDP packet from network translation port address A ₁ : a ₁ 370. Similarly, if NAT B 358 is a symmetric NAT, client A receives a UDP packet from network translation port address B ₁ : b ₁ 384. When such UDP packet traffic is detected, the server S is notified and the UDP connection 372 between NAT A and its first port 362 and between NAT B and its second port 376 is broken. This is the situation shown in FIG. 9g. Following this, the TCP connection 364 from the client A and B to the server S354 is disconnected, which depends on the applications running on the clients A and B.

FIG. 9h shows how the solution of FIG. 9g does not work when one of the NATs is asymmetric. More specifically, if NAT B358 is asymmetric, the UDP packet traffic destined for port address B: b382 to network translation address A ₁ : a ₁ 370 appears to come from B ₂ : b ₂ 392, Still received by client A via the second UDP channel 390. However, UDP packet traffic from network translation address A ₁ : a ₁ 370 to network translation address B ₁ : b ₁ 384 is blocked by NAT B 358 because its port is no longer used for communication to client B 356.

FIG. 9i shows the solution provided by this embodiment of the method for processing one NAT of an asymmetric NAT. More specifically, in step 6B, client A sees UDP packet traffic coming from network translation address B ₂ : b ₂ 392 instead of network translation address B ₁ : b ₁ 384. Accordingly, NAT A 352 switches the UDP traffic output destined for network translation address B ₁ : b ₁ 384 to network translation address B ₂ : b ₂ 392. NAT A 352 can do this because NAT B 358 uses this address to write to NAT A 352's network translation address A ₁ : a ₁ 370, and therefore IP passes. In this way, bidirectional communication is established even when there is an asymmetric NAT.

  If NATA 352 is asymmetrical and NAT B358 is symmetric, the same process as described above with respect to FIG. 9i is reversed.

  If both NAT A352 and NAT B358 are asymmetric, pure peer-to-peer communication is not possible. Traffic continues or is reestablished by the server S354 acting as an intermediary. Note that any other address that both NAT A352 and NAT B358 can see can be used as an intermediary. This approach to addressing this situation will be described in detail later with respect to the second embodiment.

  Next, a second embodiment of the present invention will be described with reference to FIGS. The second embodiment is similar in many respects to the first embodiment, so the following description will focus on the differences between the first and second embodiments. Some aspects of the first embodiment that have only been briefly described are detailed in the description of the second embodiment for completeness.

  The secure communication system 400 according to the second embodiment is distributed and may be complicated due to its size. In a sense, the overall structure can be viewed as a hierarchical tree 402 as shown in FIG. From a very high perspective, the system 400 appears as three logical levels: a system management level 404, a transmission server level 406, and an endpoint level 408. The boxes shown in FIG. 10 represent logical functions that can actually be implemented in a number of very different ways.

  The top level 404 of the tree 402 relates to the management functions of the system 400. This level 404 maintains a database 410 (see FIG. 12) of all computers authorized to use the system 400 and controls whether individual peer-to-peer communications are allowed to be established.

  Security is also controlled from this management level 404. Individual communication connections at lower levels must be authorized from administrative level 404, and after receiving such authorization, lower administrative levels negotiate encryption keys, for example, between those levels themselves You can create additional connections later.

  Further, the management level 404 is notified of the created additional connection up to a detail level that can be customized, and an event occurring at a low level can be recorded. Such events have at least each attempted access to the network.

  The management level 404 can also generate management reports regarding the operation of the network, which is extremely useful for the control and management of the system 400.

  At the lowest level 408 is an “endpoint” 412. These endpoints include “softphones” (software that handles VOIP calls) and low-colored email servers. However, the endpoint 412 may include other forms of data communication tools. Endpoint 412 is a key component installed on the user's computer to enable use of system 400 and the secure communication method provided thereby. Each endpoint 412 is inherently secure when provided to the user's location, so the storage of communications at the endpoint 412 never compromises the security of the data communication.

  Between the management level 404 and the endpoint 412, a so-called distributed “transport layer” 406 composed of a plurality of transmission servers 414 is provided. Although this layer 406 remains invisible to the user and administrator in practice, this layer facilitates the transmission of two types of communications: address and status determining communications and actual peer-to-peer data communications. In that respect, it is an indispensable component of the system 400. Only the endpoint 412 and the management layer 404 communicate via the transmission server 414 constituting the transport layer 406. This provides the advantage of simplicity and extensibility.

  Next, the management level 404 will be described in detail with reference to FIG. The management level 404 has a hierarchical tree structure that enables efficient management of the control of the system 400 in the example shown in FIG. The distributed nature of the management layer is evident from FIG. 11 and it can be seen that there is an Amteus global management node 416 running from one central location at the top of the hierarchy. Next, a client management node 418 (only one is shown in the example of FIG. 11) is provided, which can be implemented, for example, on a computer of a company or administrative body (not shown) that wants to control communication between registered users. The client at the client designated position executes the single client management node 418 shown in FIG.

  The next layer in the hierarchy is the layer 420 of a given client's regional management node 422, shown in FIG. These regional management nodes 422 connect to the endpoints 412 (EP1-EP3) via the distributed transport layer 406 (represented simply as dotted lines). This lowest management level 420 is based on geography and is important for several things including load balancing, which will be described in detail later. Similarly, in this example, yet another endpoint EP4 412 has management functions implemented directly at the Amteus global management node 416 via the transport layer 406.

  Next, how the management level 404 works will be described and shown as an example. Each user represented by the endpoint 412 is registered with one management node 416, 418, 422, generally its regional management node 422. This registration is sent up the hierarchical management tree so that the registration details are kept in all higher level management nodes 418, 416. Registration information stored in such management nodes 418, 416 includes all details regarding the user along with the current operational state of the endpoint 412 when collected during the registration process. A decision regarding whether to allow peer-to-peer communication between endpoints 412 is also obtained at the lowest level in the hierarchy where both user registration details are available. Changes that occur in the operational state of such endpoints 412 are passed to higher level management nodes.

  The EP (Endpoint) 412 is typically a telephone and / or email user. In the example shown in FIG. 11, EP1 412 is based on the client's London branch. The details of EP1 412 are stored in the London regional management node 422 and all higher level management nodes 416, 418. EP2 and EP3 412 are based in the client's Athens office. Such details are stored in the Athens regional management node 422 and all higher level management nodes 416, 418. EP4 412 is a personal Amteus subscriber known only to Amteus, and therefore EP4 412 is registered only with the Amteus global management node 416.

  Assuming EP2 412 wants to communicate with EP3 412, the Athens regional management node 422 knows both endpoint users 412 so that the request is processed locally in Athens by the Athens management node 422. Details may be sent as information to higher level management nodes 416, 418, but such higher level nodes 416, 518 are not required to set up the desired communication channel.

  If EP1 412 wants to communicate with EP2 412, EP1 412 makes a request to the local management node 422 in London. This London regional management node 422 does not know anything about EP2 412 and therefore changes the state of EP1 to call setup and passes the request to the client management node 418 on the hierarchical tree.

  The client management node 418 knows both sides of the call and can therefore process the desired call settings. The client management node 418 knows whether EP2 416 is in use because it has up-to-date status information, but, as will be discussed later, this view is not up to date and this view may be provided Is slight. If the client management node 418 considers that EP2 416 is in use, it notifies the London regional management node 422 as such, and the London regional management node 422 notifies EP1412. Thus, the setup request will fail.

  Otherwise, the client management node 418 marks the state of EP 1 as “call setup” and passes the request down to the Athens regional management node 422. Athens regional management node 422 may have EP2 416 currently in use (ie, the state of client management node 422 was not actually up to date). In that case, the Athens regional management node 422 returns a failure code “busy” to the client management node 418, and the client management node 418 cancels the request to set the communication channel as in the previous case.

  Otherwise, the Athens regional management node 422 forwards the call request to EP2 412. EP2 412 determines whether to accept the call and returns an appropriate response to EP1 412 along the path.

  If EP1 412 wishes to communicate with EP4 412, a similar process is performed. In this case, the initial request is completely passed to the Amteus global management node 416 via its regional management node 422 and client node 418. The Amteus global management node 416 then communicates directly with EP4 412 to establish a connection.

  The term “local” as used previously means that it is geographically local to the server. However, in the strictest sense, this term simply has a relative direct connection between the server and the endpoint, and the endpoint is registered with that server, so that the endpoint is local to the server. Means that.

  Referring now to FIG. 12, the transmission level 406 of the hierarchy 402 in FIG. 10 is composed of transmission servers 414 connected to each other in a hierarchical tree structure. Each transmission server 414 serves to facilitate transmission of communication from one location (endpoint) 412 to another location 412 without storing messages in the middle. At the top of the hierarchy tree, a main transmission server 424 is provided, which is connected to the Amteus global management (database) server 410 at the top of the management hierarchy. Further, a hot standby transmission server 426 is provided as a backup of the main transmission server 424 in the case of failure. In the next level 430 of the hierarchy, three regional transmission servers 1, 2 and 3 428 connected to the main transmission server 424 are shown. These regional transmission servers 428 are then connected to their respective endpoints 1.1, 1.2, 2.1 and 3.1 412.

  The aforementioned transmission level 406 represents a dynamic structure that is not predefined. More precisely, rules for dynamically connecting transmission servers 414 to configure the network are defined and provided. Furthermore, the management level 404 shown as a functionally separate layer in FIG. 10 is actually incorporated in the hierarchical network of the transmission server 406 and used for setting up peer-to-peer communication. Finally, the network incorporates a security overlay that improves network security. In this embodiment, the overlay is implemented as a functional rule that applies to all nodes in the network, ie, the rule is that for that node's endpoint 412 unless the node already knows the endpoint 412. The communication is not permitted. If the node does not personally know the identity of the desired endpoint 412, it passes the request for communication further up the hierarchy tree.

  Referring to FIG. 13, each transmission server 414 has a client link (uplink) 430 to a higher level transmission server 414 and / or a client link 432 to a management (database) server 410 (both of which are shown in FIG. 13 for convenience). Is shown). Note that when the transmission server 414 is at the top of the hierarchical tree, the uplink 430 is for the management database server 410, but is otherwise for the higher level transmission server 414. . At the bottom of the transmission server tree is an endpoint 412 as previously described with respect to FIG. Each transmission server 414 also has a downlink 434, a server connection, which allows lower level transmission servers 414 and endpoints 412 to initiate a connection to the server 414. The uplink 430 of each transmission server 414 is a TCP / IP client, while the downlink 434 is a TCP / IP server.

  Each transmission server 414 operates in an environment that does not undergo network address translation. That is, each transmission server 414 has its own public IP address 436, which may be dynamically assigned in the same manner as its own transmission server ID 438. This IP address is stored in the local database 440 along with a list 442 of endpoint IDs connected to that transmission server 414, the connection status 444 for each endpoint 412, and the permissions 446 associated with the endpoint 414. A database server 448 is provided to access and update this information as needed. The list of endpoint (user) information stored in the database 440 is configured as described below.

  The database 440 is provided with two lists, one of which is a compilation of the IDs of locally registered users who are currently online 444, and the other is a local registration where a watch is recorded. Compiling 450 of the ID of the endpoint 412 that has been performed. A watch is recorded when a particular endpoint 412 is connected but is not available for communication, for example when in use. When the watch monitors the status of the destination endpoint 412 and becomes available for communication, the watch's trigger mechanism (not shown) activates the notification process. The notification process sends a message to all of the endpoints 412 and transmission servers 414 that have recorded interest in monitoring the connection state change for the desired destination endpoint. In addition, state changes are communicated to even higher levels of the hierarchical network.

  The database 440 also stores a set of public encryption keys 451 for the endpoint 412. These are used to decrypt encrypted messages sent from various endpoints 412 as will be described in more detail later.

  The transmission server 414 also includes a positioning module 452 that determines the current geographical location of the transmission server 414 and a heartbeat monitor 454 that confirms connections to different adjacent transmission servers 414 in the hierarchical network. Server control module 456, along with database server 448, manages all such link, module and database operations.

  The network transmission server 414 must be authorized by the management system 404 (shown in FIG. 11) just like an endpoint. As described above, each transmission server 414 has its own entry in the database 440 with a user ID, along with permission to act as the transmission server 414.

  The transmission server 414 is “location aware” by the function of the positioning module 452. This can be accomplished in a number of different ways. For example, one simple method is to make the positioning module 452 Windows-based, in which case the current time zone of the system in which the positioning module is operating can be determined.

  By using the heartbeat monitor 454, all transmission servers 414 send a regular heartbeat to its parent transmission server 414 (if there is a regular heartbeat). The heartbeat is a signal for confirming the existence of a communication link between the parent transmission server 414 and the child transmission server 414, including update information related to transmission server registration connection (loading). The purpose of the heartbeat monitor 454 is to control the load balancing of the system 400. More specifically, the heartbeat information includes a count (usage count) of several endpoints 412 that are currently registered directly with the originating (regional) transmission server 414. When each (parent) transmission server 414 receives the heartbeat, it returns a message providing a list of all other transmission server downlink IP addresses and ports at the same level, plus a usage count. Thus (in FIG. 12), the main transmission server 424 returns the respective addresses and usage counts of the respective regional transmission servers 1 and 3 412 when receiving a heartbeat from the transmission server 414.

Referring now to FIG. 14, a flowchart of this aspect of the load balancing procedure 460 of this embodiment is shown. As can be seen, when a new client (endpoint 412 or lower level transmission server 414) attempts to connect to transmission server 414, at step 464, transmission server 414 requests that the new client contain a heartbeat signal. Receive. Next, transmission server 414, at step 466, uses count U ₂ of another transmission server 414 that is at the same level and at least geographically close (eg, in the same time zone) as its own stored usage count U _1. , U ₃ and U ₄ are taken out. Next, the transmission server compares its usage count U ₁ with U ₂ , U ₃ , U _{4 of} other nearby transmission servers 414 at the same hierarchical level in steps 468 and 470. If the usage count U ₁ is greater than the usage count U ₂ , U ₃ , U ₄ of someone in that mate 414, then in step 472, the new client is given a transmission server 414 (currently the lowest Return a response that tells you to connect to (has a count). Next, at step 474, the current transmission server 414 is disconnected and at step 476 the load balancing procedure 460 ends. Otherwise, the connection request is accepted in step 478, the client user count is read in step 480, and in step 482, the local usage count of the transmission server 414 is incremented by the amount of the client user count. Thereafter, the load balancing procedure ends.

  This basic principle can be extended to a higher level. For example, after the receiving transmission server 414 determines that it can accept the request at its hierarchical level and geographical location, it is a low-level transmission server that is geographically close to the new connection and can better handle that connection. Check if 414 is present. This is considered advantageous because the overall system performance is enhanced whenever a user is connected at the end of the transmission server tree. The reason is that the majority of peer-to-peer communication is usually local voice over IP traffic with tight bandwidth. Therefore, by maintaining this main traffic at the local transmission server level, the entire hierarchical system 406 is not burdened with this traffic. Otherwise, this traffic will slow down the system 400 considerably.

  The transmission server 414 accepting the new connection informs the new child user of the address of its own parent transmission server. Also, the parent transmission server 414 is notified of the connection of the new user. Thereafter, the parent transmission server 414 considers that a new user is connected.

Once connected, the new user 412 can begin sending messages to the transmission server 414 in the following categories:
Management request The transmission server 414 tags the request with its own transmission address / port 438 and then passes the request to the parent transmission server 414.
A message intended for the connected transmission server 414. This is sent in a conventional manner by TCP / IP and does not require any special operation.
A message intended for another endpoint 412 or transmission server 414 other than the parent. This message includes the user IDs of the source and destination endpoints. The transmission server 414 checks the user ID in the list of currently connected users (endpoints). This list is created by examining the list 442 of users registered in the transmission server 414 and examining the corresponding state 444. When a user is found, a message is often sent to that user via one or more lower level transmission servers 414. If the user is not found, a message is passed to the parent transmission server 414 of the transmission server. If the destination is not found after reaching the top of the transmission server tree 424, a failure is reported to the transmission source. This process effectively returns a response message from the user ID at the top of the tree to the original message sender. The process of checking the data stored in the parent 414 of each transmission server is that each registration of the user is returned to the parent of each node on the tree, so that all connection information is at the top of the tree. It depends on the facts. Therefore, if the desired user is not found at the top of the tree 424, the user may not be registered in the network.

  It should be understood that when an endpoint 412 loses direct connection to the parent transmission server 414, it will attempt to connect to its grandfather transmission server 414. The grandfather transmission server 414 can then find an alternate connection at the original level.

  At endpoint level 408 of hierarchy 402 in FIG. 10, each endpoint 412 has one client TCP / IP connection to its parent transmission server 414. This connection is used to access both the high level transmission server 414 and the management servers 410, 404.

  For example, each endpoint 412 provides a communication interface (not shown) with a user to facilitate VoIP communication. In this embodiment, each endpoint 412 also uses a so-called “multimedia” engine (not shown). This multimedia engine constitutes a microphone, speakers or headphones, a wave file player and recorder, and a video player and recorder. The multimedia engine also includes a digital signal processing module that can convert, attenuate, amplify, and mix audio between various waveform expressions. Multimedia engine functionality is common in the art, and the skilled subject matter will not require further detailed description to configure such an engine. No further explanation.

  With reference now to FIGS. 15 and 16, a method 500 for establishing a peer-to-peer connection using the system 400 described above will be described. The method 500 essentially sets whether the desired peer-to-peer connection can be established between the specified endpoints 412 in the first stage (shown in FIG. 15), and the second stage (in FIG. 16). 2), a two-stage process for establishing a peer-to-peer connection between a source 412 and a desired destination 412. After establishing a peer-to-peer connection, secure direct two-way communication between the source 412 and destination 412 is enabled using standard Internet communication protocols (in this embodiment, via a dedicated UDP channel 372). The following description relates to the first and second stages described above.

  A peer to peer (P2P) connection may be established between the endpoints 412. These connections are then used to send voice and email data in the current embodiment, but other forms of communication can also be used.

  The need for a first new P2P connection arises when an end user first decides to place a VoIP call to another end user, for example at endpoint 412. At this stage, the originator of the connection (source) only knows the network address of the desired destination (the target user's ID), and the originator knows the status of the target user (ie, whether the user is online or used Do not know. (The caller may know from the address book that the target user has recently been online, but is not convinced of the current state.)

  Referring now to FIG. 15, the method 500 for performing the first stage begins with a request in the form “I (User S) wants to communicate with User D” when the originating user 412 is at stage 502. Send to transmission server 414. The transmission server 414 examines the list 442, 444 of connected users 412 and determines in step 506 whether user D is found. If the connected user D412 is found, it is checked in step 508 whether the user D412 can talk. Otherwise, it is preferable to return a “Failed-Busy” response at step 510 and set a watch for user D at step 512. Finally, user S waits for a predetermined period of time in step 514, then tries to connect again and / or simply waits for notification of a watch operating on the current transmission server in response to a change in the possible state of user D. However, if the user D can talk at step 508, the transmission server 414 changes the state of both the user S and the user D to the “call setting process” state at step 516. Next, transmission server 414 sends a request to user D via other transmission server 414 at a level lower than the current transmission server 414 as much as possible at step 518. At this point, user D is considered found and connected at step 520 and process 500 continues as described below with respect to FIG.

  Next, if a change in the state of being available for communication occurs in the state of user D, this is notified to the local transmission server 414 of user D, and the watch setting of user S is activated. Next, user S is notified of user D's call availability at step 514 and the first phase can begin again (as described above). Alternatively or in combination, user S may wait a predetermined time at step 514 before restarting process 500 from the beginning as shown in FIG.

  As determined from the confirmation made at step 506, if user D is not currently connected to the transmission server (TS), at step 522 a confirmation is made to determine whether the parent transmission server 414 exists. Done. If there is a parent transmission server 414, a request is sent to the parent transmission server 414 at step 524. Thereafter, the parent transmission server 414 is considered the current transmission server at step 526 and the process continues with the current transmission server 414 confirming the list of end users 412 registered at step 504. If the confirmation made at step 522 determines that there is no parent transmission server 414, the transmission server sends a response indicating the connection failure to the endpoint at step 528 and the process ends at step 530.

  Outgoing requests arriving from the higher level transmission server 414 to the transmission server 414 are processed in exactly the same way, except that if the user is not connected, the request is returned instead of being forwarded instead of being forwarded. .

  Referring now to FIG. 16, the second stage of the communication process 500 will be described. Once connected, user D must tell user S the current IP address and port number so that they can connect directly to facilitate peer-to-peer communication. Accordingly, if user D is still online and available when he / she receives a call from user S, the state is changed to “call setup” in step 532. Next, user D sends a RINGING1 message to its parent at step 534, and the parent is always the transmission server 414. Also, the RINGING1 message includes the user ID of the caller (user S) so that the intermediate transmission server 414 can return the message using the same mechanism as the original call request.

  Also, when the transmission server 414 receives the RINGING1 message at step 536, it first configures the UDP (User Diagram Protocol) channel 372 at step 536. Next, step 540 constructs a RINGING2 message containing the external IP address and port number of the UDP channel, and step 540 sends this message to both endpoint user D and caller endpoint user S. The RINGING2 message also includes the user ID of the transmission server 414 that received the RINGING1 message, because that user ID is used to establish a peer-to-peer connection.

  It should be understood that the transmission server 414 never sends a RINGING1 message. Thus, a RINGING1 message that arrives at the transmission server is always considered to have come directly from the endpoint 412.

  When endpoint 412 receives the RINGING2 message at step 542, endpoint 412 checks to see if it is in a call setup state at step 544. Otherwise, at step 546, all specified for the call is reset and at step 530 the process 500 ends. In another situation, each endpoint 412 sets up a UDP channel at step 548 and begins sending messages periodically to the port specified in the RINGING2 message at step 550. This becomes the transmission server 414 closest to the called party. If there is no general network failure, most of these messages should arrive correctly.

  When the transmission server 414 closest to user D receives the first UDP message from each endpoint 412, in step 552, the endpoint's UDP channel 372 (which may be converted later, as described below). Extract network address and port number. The transmission server 414 can then return a response to each endpoint's UDP channel 372 (not shown), which includes the UDP network address and the port number of the other endpoint's UDP channel, and The response should reach each endpoint even if a firewall is present. (Because the endpoint first writes to the transmission server, this should be possible due to the normal firewall behavior at the endpoint.)

  After transmission server 414 receives packets from both endpoints, transmission server 414 knows how to address its UDP port from the outside. Next, transmission server 414 sends a TALKDIRECT message to each endpoint 412 in step 554, carrying the address of the other endpoint. After receiving such a UDP address in step 556, the endpoints 412 can communicate with the originating endpoint 412 to set up a direct UDP communication channel 372 to the destination endpoint 412 in step 556. The process 500 then ends at step 530.

  In most cases, the direct communication can be established without any problems by the above procedure. However, problems may arise if network address translation (NAT) is present at the same time as firewall operations at the endpoint. Such a problem can be overcome in many situations as previously described with reference to the example of FIGS. 9a to 9i of the first embodiment.

  The approach used for both the first and second embodiments is described in more detail later, and the mechanism for handling all the various combinations of NATs 352, 358 is also described.

  Network address translators (NATs) 352, 358 are broadly classified into two classes of translation functions: symmetric and asymmetric. Symmetric NAT uses the same Internet side address and port combination regardless of the destination of the packet, while asymmetric NAT uses a different Internet side address / port combination for each destination. Although it is not clear what this reason is, it is thought to be based on the belief that it is wise not to accept data packets from unknown sources.

  Considering a little about the necessity of these NATs, the following can be understood. 1. The recipient can know who each packet came from and can easily reject packets from unknown sources as needed without the need for NAT. 2. The IP address and port of Internet packets are easy to forge. Such strict operation by NAT is unlikely to be able to stop a highly capable hacker for a long time.

  Firewalls can also cause problems when trying to establish peer-to-peer communication. Normal firewall behavior is to impose a rule that "Don't speak until you speak". If A and B want to talk to each other, either A or B must speak first. The other can then respond. However, if A speaks first and B is behind a firewall, B will not see the packet until it is written to A.

  Reasonably effective firewall behavior requires that the rules be enforced as described above. In practice, many firewalls interpret this rule as "a person who speaks before he is spoken will not be heard again." Such behavior can cause serious problems when attempting to establish a peer-to-peer communication channel.

  In the above embodiment, several procedures are implemented to improve the situation. Initially, the asymmetric NAT usually does not open any port to write to the new destination, but becomes the original port +1 (or 2, 3 etc. depending on the number of times made between the first and second writes) Please understand that there are many cases. In this embodiment, when an asymmetric NAT is encountered, several consecutive ports above the port address indicated in the RINGING2 message are written to accommodate this possibility.

  Some manufacturers have stated that the firewall / NAT generally implements a uPnP (Universal Plug and Play) interface that may be tested and modified according to security constraints. This embodiment includes a uPnP interface (not shown) implemented on the transmission server 414.

  In some cases, a direct peer-to-peer connection cannot simply be performed because of the strict firewall implementation or because both NATs 352 and 358 are asymmetric. In such a case, this embodiment is configured to “return” the message at the local transmission server 414 acting as a trusted intermediary. This alleviates the problem of unknown senders so that the local transmission server 414 is always known to the local asymmetric NATs 352, 358, so that even the strictest rule at the firewall, for example, is such indirect pseudo-peer-to-peer. Communication is not hindered. Furthermore, the security of such indirect communication channels can be reduced by ensuring that the bounced packets are forwarded with minimal analysis and without memory by the transmission server 414 acting as a reliable intermediary. Low.

  When encountering a ridiculous (extremely strict) interpretation of firewall operation, the system is configured to perform true peer-to-peer communication in one direction and bounce at the local transmission server 414 in the other direction. This variant is worth doing because it minimizes the drop in safety. For example, when transmitting e-mail, it is advantageous to configure the e-mail to be sent directly and the acknowledgment to be bounced back.

  The following describes the actual way in which the system 10 automatically finds that there should be an asymmetric NAT 352, 358 or that a strict firewall is in place. From a high level perspective, when the local transmission server 414 knows the address of the UDP port of both endpoints 412 as described above with respect to FIG. A TALKDIRECT message indicating the address of each is transmitted to each. Endpoint 412 attempts to communicate directly and sets a timer (not shown). If the packet is received directly, the transmission server 414 is informed that the connection is busy and the timer is stopped and is no longer used. However, if no timer is received and the timer is activated (ie, the predetermined time period has elapsed), a TALKTHROUGH message is sent to the transmission server 414 and from there to the other endpoint 412 for the designated destination endpoint. 412 indicates that another communication is about to be sent directly to the local server 414. The message is then “bounced” at the transmission server 414 local to the desired endpoint 412.

  System 10 begins to establish a peer-to-peer connection before the called party accepts the call. If the call is not accepted, the peer-to-peer connection is immediately terminated. If the system 10 initiates the process only when a call is accepted and implements a time-out / TALKTHROUGH procedure, this can cause, for example, deleterious delays in establishing a voice link. This is also the case where most calls / emails are accepted (if the user logs in).

  Next, a third embodiment of the present invention will be described with reference to FIGS. The third embodiment is very similar to the second embodiment except for security issues. More specifically, the third embodiment substitutes the permission 446 stored in each node by a robust security system as described later.

  Prior art insecure communication systems cannot be used, and such communication systems obtain undesirable users that compromise the security of registered users. Known insecure products have an inherent upper limit on the number of users due to the fact that when more people use the system, the characteristics are enhanced, thereby inviting attackers to harm the “popular” system itself. is there. This effect works a little like negative feedback in a control system.

  The third embodiment attenuates this cycle by incorporating security from the beginning. Although the attacker cannot be completely eliminated from the system 10, security that is sufficiently effective is incorporated so that the presence of the attacker does not compromise the availability of the registered user's system 10. It should be understood that designing a system that completely eliminates attackers actually causes the failure of the designer.

The security requirements of the third embodiment are as follows.
Requirement 1: NODE must be authenticated by the system 10.
Requirement 2: Communication to the TS link via NODE must be confidential.
Requirement 3: CLIENT must be mutually authenticated (mutual authentication)
Requirement 4: Connection communication between CLIENT and CLIENT must be confidential.

Compliance of Security Requirements 1 and 2 Many of the following terms are from RFC 1510 (Kerberos Authentication System). Kerberos is an authentication mechanism used to verify user or host identity, which is also the preferred authentication method for Microsoft Windows Server 2003 services. The Kerberos authentication protocol provides a mechanism for mutual authentication between a client and a server or between a server and another server before establishing a network connection. This protocol assumes that the initial transaction between the client and server takes place over an insecure communication network. Such an insecure environment can be adequately exemplified by the Internet, where an attacker can easily impersonate either a client or a server, facilitating communication between a legitimate client and server. Can be wiretapped or tampered with.

  Kerberos technology relies heavily on authentication technology with shared secrets. The basic concept is quite simple. That is, if only two people know the secret, one person can verify the identity of the other person by confirming that the other person knows the secret. Passwords are kept secret using secret key cryptography. More precisely, by sharing a password, communication partners share an encryption key and use the knowledge of this key to verify each other's identity. In order for this technique to work, the shared key must be symmetric, i.e., it must be capable of both encryption and decryption with a single key. One side proves key knowledge by encrypting certain information, and the other side proves key knowledge by decrypting it.

  The basic principle is implemented by an authentication code that can function as follows. A simple protocol that uses private key authentication begins when someone outside the door wants to get inside. To gain access, the person presents an authentication code in the form of information encrypted with a private key. The authentication code information must be different each time the protocol is run, otherwise anyone who accidentally eavesdrops on the communication can reuse the old authentication code.

  When accepting the authentication code, the doorkeeper decrypts the authentication code and knows whether the decryption was successful from the inside. If the decryption is successful, the gatekeeper knows that the person who presented the authentication code has the proper key. Only two people have the proper key and the gatekeeper is one of them, so the other person should be the person who presented the authentication code.

  If the person outside the door wants mutual authentication, the same protocol with a little difference can be run in reverse. The gatekeeper can take a piece of information from the original authentication code, encrypt it with the new authentication code, and then give the new authentication code to the person waiting outside the door. The person outside the door can then decrypt the gatekeeper authentication code and compare the result with the original authentication code. If there is a match, the person outside the door knows that the gatekeeper was able to decrypt the original and should therefore have the correct key.

  FIG. 17 shows the basic principle of the method of using Kerberos technology in this embodiment. In this case, a server 602, a client 604, and a key distribution center 606 are provided. The client 604 wants to connect to the server 602 and first applies to the key distribution center (KDC) 606 to obtain a ticket that establishes a valid connection to the server 602. The ticket is effectively used to cause the server 602 already authenticated by the system 600 to authenticate the client 604.

In the detailed description of the security system according to the third embodiment, which will be described next with reference to FIGS. 18 and 19, the following initial letters are used.
TS = Transmission server 414.
NODE = combination of CLIENT and TS. Sometimes simply referred to as CLIENT or TS. In that case, the specific role described for NODE 608 is reduced, but other functions are available.
AS = authentication server 610.
KEY = value based on the password assigned to NODE 608.
TGS = ticket issuing server 612
REALM 614 = NODE 608 community sharing AS 610.

  Initially, assume that an authentication server 610 associated with a particular REALM 614 including several NODEs 608 is available. The AS 610 stores the equivalent of {USERNAME, PASSWORD} doublet for each registered NODE 608 in its local database 616. Next, as shown in FIG. 19, the client of NODE_A 608 that wants to connect to the network connects to the web server 620 of the KDC 610 to register using the Internet browser 618, whereby the user name “UserA” 622 and the password “pwdA”. Assume that 624 is acquired.

The basic mechanism of the procedure is explained using the following initials.
NODE_A = NODE 608 with user name A.
Ticket granting ticket 626 of TGT_A = 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 that allows NODE_A to obtain access rights to NODE_B.
{X} K_Y = value X encrypted with key K_Y.

18 and 19, at the beginning of the authentication process, NODE_A 608 is activated and authenticated to the system 600 as shown below.
1. The NODE_A 608 is connected to the TS 414 and sends an AS_REQ 634 message to the AS 610 of the REALM 614 to which the NODE_A 608 belongs (generally this message goes back up the hierarchical network until a TS 414 connected to the AS 610 is found).
2. The AS 610 generates a session key S_A 628 and returns an AS_RESP message 636 that includes TGT_A 626 and S_A 628 encrypted together with pwdA 624.

  The AS 610 can also return an encrypted TIMESTAMP (not shown) to increase authentication security. This assumes that AS 610 receives time from a trusted source via Network Time Protocol (NTP) or a simple NTP connection and NODE 608 is synchronized with the AS time when receiving system 600 authentication. . NODE 608 must associate the TIMESTAMP sent from the AS with its current Win32 tick count and calculate a new current time when it needs to generate its own TIMESTAMP value.

After NODE_A 608 is authenticated, the network is informed of the name of the TS 414 that must currently “link” to join the network (ie, can make and receive VoIP calls), and the target TS 414 is called NODE_B 608. Assume that If a time stamp is used, the procedure is as follows.
1. A TGS_REQ message 638 containing the names of TGT_A 626 and NODE_B 608 is sent to AS 610.
2. The AS 610 returns a TGS_RESP message 640 containing K_AB 630 (encrypted with S_A 628) and TICKET_AB 632.
3. NODE_A 608 extracts the value of K_AB 630, calculates the current TIMESTAMP value, and generates an authentication code in NODE_B 608 as {TIMESTAMP} K_AB. NODE_A 608 sends an AP_REQ message 642 to NODE_B 608 that includes {TIMESTAMP} K_AB and TICKET_AB 632 to NODE_B 608.
4). In order for NODE_B 608 to allow NODE_A 608 to link, NODE_B must be able to decrypt TICKET_AB 632 and extract K_AB 630 and then decrypt {TIMESTAMP} K_AB to verify TIMESTAMP. Assuming this was successful, NODE_B 608 returns an AP_RESP message 644 containing {TIMESTAMP + 1} K_AB that allows NODE_A 608 to authenticate NODE_B 608.

  It will be readily apparent to the skilled subject how the above operations will be performed without the use of a time stamp, and therefore, how to execute the above sequence of events without a time stamp. No further explicit explanation will be given.

  At this point, NODE_A 608 is “linked” to the network via NODE_B 608 (actually, CLIENT 604 of NODE_A becomes the TS 414 server of NODE_B 608).

  The above embodiments are based on an adapted subset of the Kerberos authentication system and reuse basic protocols, messages and data structures, but effectively use the new authentication techniques of this embodiment in the context of peer-to-peer communication Different functions are available.

Conformance to security requirements 3 and 4 The following acronyms are used to describe this stage of the authentication process.
Diffie-Hellman public key 646 for DH_PK_A = CLIENT_A.
DH_SK_A = CLIENT_A Diffie-Hellman secret key 648.
DH_PK_B = CLIENT_B Diffie-Hellman public key 650.
DH_SK_B = CLIENT_B Diffie-Hellman secret key 652.
K_AC = shared key 654 between NODE_A and NODE_C.

  Referring now to FIG. 19, when CLIENT_A 604 in NODE_A 608 currently connected to the network wants to call CLIENT_C 604 in NODE_C 608, this embodiment is established between them with CLIENT 604 authenticating each other. Subsequent communication over the connection (such as a peer-to-peer connection) requires that it be encrypted with the shared key K_AC 654.

Consider the two types of authentication possible between CLIENT and CLIENT. The first such authentication is referred to as “Authentication-by-induction” and is effectively an authentication that should be between NODE_A 608 and NODE_C 608 before the connection between CLIENT_A 604 and CLIENT_C 604 can be established. Take the link chain. The procedure is as follows.
1. CLIENT_A 604 generates a Diffie-Hellman (DH) key pair and sends a message containing DH_PK_A 646 to CLIENT_C 604. This message is sent over the authenticated link chain 656 connecting those clients (as part of the communication channel setup protocol).
2. Upon receipt of the message, CLIENT_C 604 assumes that the message should have been sent from an already authenticated source (CLIENT_C 604 is not in a position to formally authenticate the source, and thus this form of authentication. Indirect weak expression is "authentication by induction").
3. CLIENT_C 604 generates a Diffie-Hellman (DH) key pair and sends a message containing the value of DH_PK_B 650 to CLIENT_A 604. The message is sent to CLIENT_A 604 via the same (but different) authenticated link chain 656.
4). At this time, both CLIENT_A 604 and CLIENT_C 604 are in a position to independently calculate the shared key K_AC 654. The side that intercepts DH_PK_A 646 or DH_PK_B 650 is not in a position to calculate K_AC 654 and to deceive CLIENT_A 604 or CLIENT_C 604.
5. CLIENT_A 604 and CLIENT_C 604 use K_AC 654 to generate a large number of encryption keys for the Advanced Encryption System (AES) or equivalents to enable reliable communication.

In general, “authentication by guidance” is not true authentication, but rather is summarized as follows.
“I have established a confidential call with an authenticated party X (whose name is X), but I have no way to verify it.” (VoIP calls are less worrisome than e-mails, for example. Is obvious).

  Also, the AS 610 can be used to generate a TICKET 632 that allows CLIENT_A 604 and CLIENT_C 604 to authenticate each other, but the temporary overhead in performing this operation as part of the communication channel configuration is too great. Therefore, “authentication by guidance” is used in preference to this alternative.

  A second possible type of authentication is provided externally to Amteus system 600, which Amteus system 600 must interoperate with. Assume that an externally provided public key infrastructure (PKI) is available and CLIENT is public key available (PKE). In such a situation, the protocol described above is extended to the RSA cryptographic algorithm that digitally signs messages sent between CLIENT_A 604 and CLIENT_C 604, so that strong authentication is available (PKI is sufficient in the art). Therefore, a more detailed discussion of PKI will not be given here).

  This embodiment uses a less secure and more practical “guided authentication” approach.

Authentication Server Replication In the prior art Kerberos system, the management of the security database for authentication is kept as simple as possible, and the same principle applies to this embodiment. The features of this embodiment are as follows.
-Keep only static data and try to avoid storing session or call related data (ie dynamic data).
Create an account, modify account details, and maintain a read / write master copy to delete the account.
-Duplicate the master copy regularly into several read-only copies.

Cross Realm Authentication In this embodiment, there may be a plurality of REALMSs 614 that are organized hierarchically for the management system 404. At this point, authentication between NODEs 608 in different REALMSs 614 (so-called “cross-realm authentication”) is performed.

  Cross-realm authentication effectively rides on the existing TGS (Ticket Granting Service) system 600 described above. If NODE_A 608 in REALM_A 614 wants to link to NODE_B 608 in REALM_B 614, TGS_B 638 and 340 need to be registered in AS 610 for REALM_A 608. Thus, NODE_A 608 simply requests TGT 626 from TGS_A at step 634, which TGT 626 is sent to TGS_B to obtain a TICKET 632 to send to NODE_B 608 to achieve the new link.

  Even if the realms 614 are organized hierarchically (see FIG. 21), typically the two communication realms 614 must register with each other, not just in one direction.

  In the following, cross realm authentication and authorization will be described in more detail. However, before that, the outline of the NODE security operation used in the embodiment will be described with reference to FIGS. 20a and 20b.

  In general, NODE 608 is a collection of subsystems, and its associated subset is shown in FIGS. 20a and 20b. A connection or link to NODE 608 is made. Here, a simple connection that does not require NODE-NODE encryption is distinguished from a link with associated encryption keys 630, 654 in a more permanent configuration.

  20a and 20b show two NODEs 608, both of which contain the same subsystem (ie, these nodes are different examples of the same executable subsystem). The parent NODE 608 (FIG. 20a) is the primary NODE in that the data client (DC) 656 is connected to the data server (DS) 612 and the KDC 610 is active. Child NODE 608 (FIG. 20b) is not connected to DS, so DC656 and KDC610 are present but not active. The primary NODE 608 uses the security service 660 to process all security requests received from its children.

  CLIENT 604 and TS 414 communicate with SS 660 using a handle (not shown). A handle is associated with each connection or link (ie, each active server stream) regardless of the CLIENT connection / link 662 to the parent NODE 608 or the TS connection / link 664 from the child NODE 608.

  When NODE 608 is activated, DC 656 attempts to connect to DS 658 and log in, and if successful, KDC 610 is also initialized. Note that it is not necessary to authenticate the primary NODE 608 to its own KDC 610 because the CLIENT 604 cannot link to another NODE 608 in the same REALM 614, as will be seen later.

  In almost all cases, the CLIENT subsystem attempts to establish a link 662 to the parent NODE 608 (this also applies to the main NODE 608, in which case the link is a cross-realm as will be shown later). SS 660 is instructed to construct a security request to send to parent NODE 608 and to process the security response received from parent NODE 608. After the link to the parent NODE 608 is established, the CLIENT 604 can send a call to the SS 660 to encrypt or decrypt the link message. If an appropriate call is not made to SS 660 and CLIENT 604 receives a security message, ie if this NODE 608 is not the target of the message, CLIENT 604 will send the message to TS 414 until the message reaches the selected destination NODE 608 and is consumed. Send down the hierarchy further.

  Child NODE 608 communicates the message to TS 414. If TS 414 identifies the message as a security message, an appropriate call to SS 660 is made, i.e., if the call fails or if the target goes further up the hierarchy, TS 414 passes to the parent NODE 608. Send security message to CLIENT 604 for delivery.

  If an active (connected to DS 658) KDC 610 is available at NODE 608, this KDC 610 is the primary NODE 608, so the security request received from the child at TS 414 must be satisfied by this NODE 608, and higher. Not sent.

Note: The simplest implementation is that CLIENT 604 assigns several states to link configuration management. The SS 660 does not return a call to the CLIENT 604 or the TS 414. Assume that the subsystems are tightly integrated so that CLIENT 604 and TS 414 must maintain state to manage security requests and responses.

  A REAL 614 is a set of registered users (similar to Windows Domain), as described above, where each user is registered with that REAL 614 (generally by the web server 620) and on the DS 612 of that REAL 614. Have a maintained account (not shown).

  Referring now to FIG. 21, a DS (data server) 612 holds all authentication data for a particular REALM 614, and this data does not spread outside the created REALM 614. The primary NODE 666 is essentially the root of REALM 614's security, and security requests are not allowed to go up the hierarchy.

  In order for dynamic data to be able to travel up and down the hierarchy, some means of joining a child NODE 668 in one REALM 614 to an appropriate parent NODE 670 in a “higher” REALM 614 is needed, and the nature of the tree topology Requires only one such link 672. FIGS. 20 and 21 illustrate the solution provided by this embodiment, where the primary NODE 666 of REALM A 614 is allowed to link to the parent NODE 670 in the “higher” REALM B 614. This link 672 is possible because an account is set up in DS B 612 so that the main 666 of REALM A 614 can be authenticated to REALM B 614 and a link 672 can be created.

  Since link 672 is a cross realm, call data can now travel from REALM A 614 to REALM B 614 and down to REALM C 614, and NODE X 608 can make a cross realm VoIP call 674 to NODE Y 608.

  Next, a detailed scenario illustrating how cross realm links are achieved will be described.

Primary NODE: Startup Assume that the data server (DS) 612 is already running. The primary NODE 666 starts locally with respect to the DS 612 and is generally supplied with command arguments that allow it to log into the DS 612 and generate the KDC key 628 (the secondary NODE is started with the same arguments). ) An arbitrary {username, password} is provided by the GUI to log into a higher level REALM 614 account.

1. The bootstrap sequence instructs a DC (data client) 656 to log into the local DS 612.
2. The bootstrap sequence calls the procedure procedureSecurityService :: Initialise (). KDC 610 generates the key and establishes a handshake with DC 656.
3. The user enters {user name, password} so that CLIENT 604 can link to the parent NODE 670 (in another REALM 614).
4). The CLIENT 604 obtains a handle for a new connection to the parent node 656 by the procedure SecurityService :: CreateSecurityContext ().
5. CLIENT 604 calls the procedure SecurityService :: BuildAsReq () to build the AS_REQ message 634 and then sends the AS_REQ message 634 to the parent NODE 670.
6). The CLIENT 604 receives the AS_REP message 636 and passes it to the procedure SecurityService :: ProcessAsRep ().
7). The CLIENT 604 calls the procedure SecurityService :: BuildTgsReq () with the ID of the NODE that it wishes to connect to, so the SS (Security Service) 660 can build an appropriate TGS_REQ message 638. A TGS_REQ message 638 is sent to the parent NODE 670.
8). The CLIENT 604 receives the TGS_REP message 640 and passes it to the procedure SecurityService :: ProcessTgsRep ().
9. At this point, CLIENT 604 promotes the existing link connection state or facilitates reconnection to another parent NODE 670 (but in either case, the target NODE is the NODE specified in the procedure BuildTgsReq () call). Must). CLIENT 604 calls the procedure SecurityService :: BuildApReq () to construct the AP_REQ message 642, and then CLIENT 604 sends it to the parent NODE 670.
10. The CLIENT 604 receives the AP_REP message 644 and passes it to the procedure SecurityService :: ProcessApRes (). When this call is successfully completed, SS660 should have the security context needed to support the encryption / decryption operation on link 672 to parent NODE 670.

Non-main NODE: Activation NODE 608 is not supplied with a DS login argument, so the bootstrap sequence does not instruct DC 656 to log in to local DS 612.
2. The bootstrap sequence calls the procedure SecurityService :: Initialise (). The KDC 610 is not supplied with parameters for generating a key, and the DC 656 indicates that the KDC 610 is not connected to the DS 612.
3. The user enters {username, password} to allow CLIENT 604 to link to the parent NODE in the same REALM 614 (the link may or may not be for the primary NODE 666).
4). CLIENT 604 obtains a handle for a new connection to the parent node by the procedure SecurityService :: CreateSecurityContext ().
5. The CLIENT 604 calls the procedure SecurityService :: BuildAsReq () to build the AS_REQ message 634 and sends the AS_REQ message 634 to the parent NODE.
6). The CLIENT 604 receives the AS_REP message 636 and passes it to the procedure SecurityService :: ProcessAsRep ().
7). The CLIENT 604 calls the procedure SecurityService :: BuildTgsReq () with the ID of the NODE 608 that it wishes to connect to, so the SS 660 can build the appropriate TGS_REQ message 638. A TGS_REQ message 638 is sent to the parent NODE.
8). The CLIENT 604 receives the TGS_REP message 640 and passes it to the procedure SecurityService :: ProcessTgsRep ().
9. At this point, CLIENT 604 facilitates reconnecting to an existing link connection state or another parent NODE (but in any case, the target NODE must be the NODE 608 specified in the procedure BuildTgsReq () call). . CLIENT calls the procedure SecurityService :: BuildApReq () to build an AP_REQ message 642 that CLIENT 604 sends to the parent NODE.
10. The CLIENT 604 receives the AP_REP message 644 and passes it to the procedure SecurityService :: ProcessApRes (). Upon successful completion of this call, SS660 should have the security context necessary to support encryption / decryption operations on the link to the parent NODE.

Primary NODE: Assume that an AS_REQ or TGS_REQ request is received from a child NODE. Primary NODE 666 is initialized and has a KDC 610 that can accept security requests.

1. TS 414 receives AS_REQ message 634 from child NODE 668. If the connection / link has a security context, the procedure SecurityService :: DecryptLinkData () is called to decrypt the message.
2. The TS 414 passes the AS_REQ message 634 to the procedure SecurityService :: ProcessAsReq (). To satisfy the request, the KDC 610 extracts the username from the AS_REQ message 634 and requests the password (hashed) held in the DS 612 (by DC 656) using the username.
3. If this succeeds, the procedure SecurityService :: ProcessAsReq () returns an AS_REP message 636. (Note: When SS660 is processing a request, no security context is required. This is different from when SS660 is processing a response).
4). TS 414 sends an AS_REP message 636 to the child NODE 668 that sent the AS_REQ message 634.

  If the primary NODE 666 receives a TGS_REQ message 638, it follows the same procedure (except that the DS 612 requests a (hashed) password for the linked NODE 608).

Non-primary NODE: Receive AS_REQ or TGS_REQ from child NODE TS 414 receives AS_REQ message 634 from child NODE 668. If the connection / link then has a security context, the procedure SecurityService :: DecryptLinkData () is called to decrypt the message 634.
2. TS 414 passes an AS_REQ message 634 to the procedure SecurityService :: ProcessAsRe (), which returns an appropriate error code to indicate that the active KDC 610 is not available.
3. TS 414 sends an AS_REP message 636 to CLIENT 604 to be passed to parent NODE 670.

Primary or non-primary NODE: Any NODE 608 that receives an AP_REQ message 642 that receives an AP_REQ must either successfully process the message locally or return an error message and cannot pass the message.

1. TS 414 receives AP_REQ message 642 from child NODE 668. The existing security context, and thus the link, should not be available for this connection, so there is no need to decrypt the message.
2. TS 414 passes the AP_REQ message 642 to the procedure SecurityService :: ProcessApReq (), which uses its local NODE password (not KDC 610) to process and generate an appropriate AP_REP message 644 to return. To do. If the procedure SecurityService :: ProcessAsReq () is successful, a complete security context is established and the connection to the child NODE 668 is in the link promotion state.
3. TS 414 returns an AP_REP message 644 to child NODE 668.

Primary or non-primary NODE: Receive AS_REP or TGS_REP from parent NODE If CLIENT 604 in primary NODE 666 receives AS_REP message 636 or TGS_REP message 640, primary NODE 666 is not the origin of original AS_REQ message 634 or TGS_REQ message 638 Rather, we have already considered the case of launching before (there should be no existing security context).

  If the NODE 608 that receives the AS_REP message 636 or the TGS_REP message 640 is not the primary NODE 666, the request is sent to the TS 414 to drop to the appropriate child NODE 668. In this case, there must be a security context for link 672 to parent NODE 670 and the procedure SecurityService :: DecryptLinkData () is called to decrypt the received message. The link 672 down to the child NODE 668 may or may not have a security context (the child NODE 668 may send an AS_REQ 634 and a TGS_REQ message 638 to the higher level KDC 610 to link to this NODE 608). .

Primary or non-primary NODE: Receive AP_REP from parent NODE This has already been described for the activation case.

  The above description refers to some procedures such as SecurityService :: DecryptLinkData (), but the details of these procedures are the comparison of the functions of these procedures in a given situation and to implement the above functions. It is to be understood that this detail is not critical and therefore this detail is part of the skill and knowledge of the skilled subject matter herein.

  The above embodiments have been described using a push mechanism that transmits the latest status of registered users online. However, in an alternative embodiment, this may be by a pull mechanism where the email server identifies the person sending the email and then requests that person's status information from the DS. The advantage of the pull mechanism is that the transmission overhead of this data server is minimized. However, the advantage of the push mechanism is that it is easy to use for email servers.

  It should be understood that the present invention is not limited to the specific embodiments described above. For example, an email message to be sent can be divided into a plurality of separately encrypted parts and each part. Each part can then be sent separately to the respective transmission server mechanism. Each part is sent separately to the destination and can be decrypted and reconstructed by a designated recipient. The advantage of this is that even if a single email message is intercepted and successfully decrypted, the message is not disclosed. This is a very robust way to improve communication security. In general, e-mail text can be sampled to obtain a portion of the sent message, eg, using 5 TSMs, every 5th character of the e-mail text is sampled and One of them can be created. Other email messages are also sampled at every fifth character, but each email message will have a different offset than the first email message.

  It should be understood that the present invention is also applicable to wireless communication networks (such as networks using WIFI) without using wired networks. In addition, as a source and destination communication device in this peer-to-peer communication system, a PDA (personal digital assistant) and a mobile phone can be used instead of a computer.

  Finally, the skilled subject will appreciate that other encryption techniques that are not PKI can be used.

1 is a schematic block diagram of a system according to an exemplary embodiment of the present invention. FIG. 2 is a schematic diagram illustrating an example of how the system of FIG. 1 can be used to enable peer-to-peer communication between two users Bob and Alice. It is a block diagram which shows the whole operation method of the personal e-mail server of FIG. FIG. 4 is a block diagram of a Connect from Client subroutine of the method of FIG. FIG. 4 is a block diagram of a Message Receive subroutine of the method of FIG. FIG. 4 is a block diagram of a Message Waiting To Send subroutine of the method of FIG. It is a flowchart which shows the interaction between the transmission server mechanism for determining the specific address of a designated recipient, and a mail server. FIG. 2 is a schematic diagram illustrating various uses of a system with various entities. FIG. 3 is a schematic block diagram illustrating a survey performed by TSM in determining a specific recipient's unique IP address. FIG. 3 is a schematic block diagram illustrating a survey performed by TSM in determining a specific recipient's unique IP address. FIG. 3 is a schematic block diagram illustrating a survey performed by TSM in determining a specific recipient's unique IP address. FIG. 3 is a schematic block diagram illustrating a survey performed by TSM in determining a specific recipient's unique IP address. FIG. 3 is a schematic block diagram illustrating a survey performed by TSM in determining a specific recipient's unique IP address. FIG. 3 is a schematic block diagram illustrating a survey performed by TSM in determining a specific recipient's unique IP address. 9a and 9f show how the investigations performed in FIGS. 9a to 9f can be applied to a symmetric NAT case and an asymmetric NAT case. 9a and 9f show how the investigations performed in FIGS. 9a to 9f can be applied to a symmetric NAT case and an asymmetric NAT case. 9a and 9f show how the investigations performed in FIGS. 9a to 9f can be applied to a symmetric NAT case and an asymmetric NAT case. It is a schematic block diagram which shows the whole functional tree structure of the 2nd Embodiment of this invention. It is a schematic block diagram which shows the hierarchical property of the management level of the tree structure of FIG. It is a schematic block diagram which shows the hierarchical property of the transmission server layer of the tree structure of FIG. It is a schematic block diagram which shows the functional element of the general transmission server of the transmission server layer of FIG. 11 is a flow diagram illustrating a process of load balancing new connections to the management layer of FIG. 12 is a flow diagram illustrating a first stage of establishing a peer-to-peer connection using the network of the second embodiment of FIG. 12 is a flow diagram illustrating a first stage of establishing a peer-to-peer connection using the network of the second embodiment of FIG. 12 is a flow diagram illustrating a first stage of establishing a peer-to-peer connection using the network of the second embodiment of FIG. FIG. 11 is a flow diagram illustrating a second stage of establishing a peer-to-peer connection using the network of the second embodiment of FIG. It is a schematic block diagram which shows how the principle of the Kerberos technique is applied in the 3rd Embodiment of this invention. It is a block diagram which shows the main stage of 3rd Embodiment at the time of trying to connect to a network. FIG. 2 is a schematic block diagram showing details of how to register with a central data server from a network security perspective and then support peer-to-peer communication. FIG. 20 is a schematic block diagram of a parent node of the hierarchical network of FIG. 19. FIG. 20 is a schematic block diagram of child nodes of the hierarchical network of FIG. 19. FIG. 3 is a schematic block diagram illustrating how a cross realm link is achieved in implementing a peer-to-peer call between user computers X and Y.

Claims (116)

A method of performing secure peer-to-peer data communication, such as email communication, via a data communication medium between a first remote computer and a second remote computer,
Receiving the address details of each remote computer and the current state of the connection to the data communication medium;
Generating a data communication at a first remote computer;
Checking the current connection status of the second remote computer;
Data communication from the first remote computer to the second remote computer without storing the data communication only when it is found from the connection state of the second remote computer that it is currently connected to the data communication medium. Sending directly.   The method of claim 1, wherein the receiving step is repeated each time the connection state of any of the remote computers changes. Requesting the connection status of the second remote computer from the data server storing the current status;
The method of claim 1, wherein the receiving step is performed in response to the requesting step.   4. A method according to any one of claims 1 to 3, further comprising the step of providing the data server with address details of the first remote computer and the current state of the connection to the data communication medium.   5. The method of claim 1, further comprising encrypting the data communication with information about the second remote computer so that only the second remote computer can decrypt the communication when received. The method according to item.   The method of claim 5, wherein receiving comprises receiving information about the second remote computer to perform the encrypting step.   The first remote computer includes a plurality of locally interconnected secure computers at the first remote location, and the generating step is on a computer separate from the receiving step, the verifying step and the transmitting step. 7. The method according to any one of claims 1 to 6, wherein the method is performed in Storing a set of permissions regarding the ability of remote computers to communicate with each other;
Confirming permission of the first remote computer to communicate with the second remote computer;
8. The transmitting step is allowed only if the step of confirming that the first remote computer is found to have permission to communicate with the second remote computer. 2. The method according to item 1.   9. The method of any one of claims 1 to 8, further comprising verifying the identity of a designated recipient designated to be a second remote computer in data communication. If the connection status of the second remote computer indicates that the second remote computer is currently unable to receive messages via the data communication medium, the data communication is made local after the confirmation step. Temporarily storing and waiting for a predetermined period of time;
The method according to any one of claims 1 to 9, further comprising the step of repeating the step of confirming and the step of transmitting thereafter. If the transmission of the data communication from the first remote computer to the second remote computer is evaluated and the transmission fails,
Determine the cause of the transmission failure and, depending on the determined cause,
Generating a transmission failure notification at the first remote computer;
The method according to any one of claims 1 to 10, further comprising the step of performing any of the steps of repeating the step of waiting and transmitting for a predetermined time period. Further comprising the step of dividing the data communication into a plurality of individual data messages;
12. The method according to any one of claims 1 to 11, wherein the step of sending further comprises sending each of the data messages separately to a second remote computer, thereby improving the security of the data communication procedure. Method.   13. A method according to any one of claims 1 to 12, wherein the data communication comprises voice over IP communication. A communication server, which performs secure peer-to-peer data communication such as e-mail communication between a first remote computer including the communication server and a second remote computer via a data communication network. Configured,
Receiving means for receiving address details and current status of the connection of each remote computer to the data communication network;
A message generation module for generating data communication in a first remote computer;
A confirmation module for confirming the current connection status of the second remote computer;
Only when it is determined from the connection state of the second remote computer that the second remote computer is currently connected to the data communication network, the first remote computer does not store the data communication halfway. A communication module configured to send data communication directly to a second remote computer. A communication system,
A plurality of communication servers according to claim 14;
A data server connectable to a plurality of communication servers via a data communication network,
A data server receives, collects and stores the current state of each communication server's connection to the communication network along with each communication server's current network address and forwards at least a portion of this information to a plurality of communication servers; A communication system configured to allow such communication servers to perform peer-to-peer communication between a plurality of communication servers.   The communication system of claim 15, wherein the central data server is configured to look up current addresses of a plurality of communication servers using a user diagram protocol (UDP). A communication server configured to assist in establishing peer-to-peer data communication, such as email communication, between a first and second user computers over a data communication network, the server comprising a plurality of communication servers Provided to a given hierarchy level in the server network
Connection means for enabling the communication server to operatively connect to other communication servers at other hierarchical levels in the server network;
Registration means for registering a plurality of local user computers in a communication server;
A data store for storing registration details of each registered local user computer, wherein the registration details include address information of each local user computer and a data store including a current state of connection to the data communication network;
The connecting means transfers the stored registration details to the adjacent communication server at the next higher hierarchical level of the server network, and the registration details of any local user computer of the connected communication server at the lower level in the hierarchical network. A communication server configured to receive and store.   18. The stored registration details include a server network identification of a communication server, a server network identification of at least one registered local user computer, and a current state of connection of the local user computer with the communication server. Communication server.   19. A communication server according to claim 17 or 18, wherein the stored registration details include a server network identification of the communication server from a lower level in the hierarchy and a server network identification of a registered local user computer of the lower level communication server.   20. A communication server according to claim 18 or 19, wherein the stored registration details include a global network address of each user computer registered locally.   The communication server according to any one of claims 17 to 20, wherein the stored registration details include a public encryption key of each user computer registered locally.   When the connection means receives a request to establish a connection to the second user computer, it checks the data store for the local registration of the second user computer and the identity of the second user computer is stored in the local data store. A communication server according to any one of claims 17 to 21, configured to accept a request when   The registration confirmation means is configured to instruct the connection means to forward the request to an adjacent communication server when it is not known that the second user computer is registered locally. The communication server described.   The connection means further includes a status check means configured to check the data store with respect to the status of the registered user computer, wherein the connection means registers the second user computer and the status of the second user computer 24. The communication server according to claim 22 or 23, configured to attempt to establish communication with a second user computer when it can be determined that a connection to the second user computer can be established.   The communication server according to any one of claims 22 to 24, wherein the connection means is configured to update the state of the second user computer in response to accepting the request to connect to the second user computer. .   26. Any one of claims 22 to 25, wherein the connection means is configured to set a data connection state of the first and second user computers in response to accepting a request to connect to the second user computer. The communication server described in 1. Response means configured to configure a response to the request for connection to the second user computer;
18. The response means is configured to send the current network address of the second user computer to the first user computer and send the current network address of the first user computer to the second user computer. 27. The communication server according to any one of to 26.   28. The communication server of claim 27, wherein the response means is configured to determine a global network address of the second user computer.   30. The communication server of claim 28, wherein the global network address includes a UDP channel address. The data store further includes a set of permissions regarding the ability of the remote computers to communicate with each other;
30. The server further includes means for determining whether the first user computer is authorized to communicate with the second user computer using the stored set of permissions. The communication server according to any one of the above. A communication system for performing secure peer-to-peer data communication such as e-mail communication between specific user computers among a plurality of user computers via a data communication network,
18. A plurality of communication servers according to claim 17, arranged in a hierarchically connected server network, each representing a node of the server network, wherein the server network is a specific user computer of the plurality of user computers A communication system that can be connected to a plurality of user computers to assist in establishing communications between them. A method for assisting in establishing secure peer-to-peer data communication, such as email communication, between a first and second user computers via a data communication network, in a server network comprising a plurality of communication servers Implemented on a communication server at a hierarchical level of
Establishing operable network connections to communication servers at other hierarchical levels in the server network;
Registering multiple local user computers with a communication server;
Storing registration details including address information of each local user computer and the current state of connection to the data communication network for each registered local user computer;
The establishing step transfers the stored registration details to a neighboring communication server at a next higher hierarchical level in the server network; and any local of a connected communication server at a lower level in the hierarchical network. Receiving and storing registration details of the user computer. Method for locating a designated recipient computer of a peer-to-peer communication message to assist in establishing secure peer-to-peer data communication, such as email communication, over a data communication network between a sender computer and a designated recipient computer Implemented in a hierarchical network of communication servers,
Sending a request for data communication including the identification of the designated recipient computer and the identification of the sender computer to the local server;
Determining whether the designated recipient is known to the local server;
Retrieving stored details about the designated recipient if the designated recipient is known to the local server and sending the details to the sender computer;
Forwarding the request to the next communication server at the next higher hierarchical level in the server network when the designated recipient is not known locally, thereby making the communication server a local server;
A method comprising the steps of determining, retrieving and repeating forwarding until a designated recipient is found or the top server in the hierarchical network is verified.   34. The method of claim 33, further comprising sending a connection failure notification to the sender computer when the top of the hierarchical network is reached without identifying the designated recipient computer.   35. A method according to claim 33 or 34, further comprising the step of verifying the status of the connection to the designated recipient computer after the designated recipient computer is identified.   36. The method of claim 35, further comprising sending a connection failure notification to the sender computer if a connection to the designated recipient computer is not available.   37. The method further comprises the steps of waiting for a predetermined period of time to allow for a possible state change and then performing again the steps of transmitting, determining and retrieving, transferring and repeating. the method of.   The retrieving step includes sending a request to a communication server at a lower level in the hierarchy in which the designated recipient is registered if the designated recipient is known to the communication server but not registered locally there. 38. A method according to any one of claims 33 to 37.   40. The method of claim 38, wherein the retrieving step includes retrieving the network location of the designated recipient from a server registered locally as part of the stored details of the designated recipient.   The method further includes storing and executing a monitoring function for future use in finding a desired designated recipient computer, wherein the monitoring function identifies the identity of any new computer added to the local server. 40. A method according to any one of claims 33 to 39, further comprising the step of comparing to the identification of and notifying the sender computer if there is a match.   Using a stored set of permissions, the sender computer determines whether communication with the desired designated recipient computer is permitted, and the stored permissions allow such communication 41. A method according to any one of claims 33 to 40, wherein the step of transmitting only can be performed. A method of establishing secure peer-to-peer data communication, such as email communication, between a sender computer and a designated recipient computer over a data communication network, implemented in a hierarchical server network comprising a plurality of communication servers,
A method for searching for a designated recipient computer according to any one of claims 33 to 41;
Communicating the current global communication address of the designated recipient computer to the sender computer;
Communicating the current global communication address of the sender computer to the designated recipient computer;
Establishing a peer-to-peer communication channel between a sender computer and a designated recipient computer using a global communication address. Storing a set of permissions regarding the ability of remote computers to communicate with each other;
Confirming a stored set of permissions for the ability of the sender computer to communicate with the designated recipient computer;
Further comprising allowing the first and second communication steps and the transmission step to be performed only if it is found from the checking step that the sender computer has permission to communicate with the designated recipient computer; 43. The method of claim 42.   44. The method according to claim 42 or 43, further comprising setting up a first direct channel between the sender computer and the local server.   45. The method of claim 44, wherein the second communication stage is performed via a first direct channel.   46. A method according to any one of claims 42 to 45, further comprising establishing a second direct channel between the designated recipient computer and the local server.   47. The method of claim 46, wherein the first communication stage is performed via a second direct channel.   48. A method according to any one of claims 44 to 47, wherein setting up the first or second direct channel comprises setting up a first or second UDP (User Diagram Protocol) direct channel. A transmission server used to establish peer-to-peer data communication, such as email communication, between a first and second user computer,
Receiving means for receiving from the first user computer a request for connection to the second user computer registered in the transmission server;
Verification means for verifying a current connection state of the connection to the second user computer;
A data store that stores details of the request as a watch if it is determined from the current connection state of the second user computer that peer-to-peer communication with the second user computer cannot currently be established;
In response to the verification means, if the status of the second user computer has changed and it is indicated that peer-to-peer communication with the second user computer can now be established, the second user computer's online status Responding means for sending to the first user computer a message indicating
The verification means is configured to periodically check and update the current connection status to the second user computer, and responding when it is found from this update that the status of the second user has changed online A transmission server that confirms the presence of a watch and activates a response means to send a message when the watch is found.   50. The transmission server of claim 49, wherein the data store is configured to store an identification of the second user computer and an identification of the first user computer.   The receiving means is configured to receive a plurality of requests for connection to the second user computer, the data store is configured to store details of each request of the watch to the second user computer, and the response means includes: 51. The apparatus according to claim 49, wherein the plurality of messages are transmitted one by one to each of the user computers that have requested connection to the second computer after the connection state of the second user computer has changed to online. The transmission server described in 1.   52. The transmission server according to any one of claims 49 to 51, wherein the transmission server is configured to be connected to a hierarchy of transmission servers.   The transmission server is configured to send details of the connection status of each registered user computer to the transmission server at a higher position in the hierarchy, and the response means sends a message indicating the online status of the second user computer. 53. The transmission server of claim 52, configured to transmit to at least one transmission server that is higher in the hierarchy. The data store is configured to store a plurality of different watches for different ones of the user computers registered in the transmission server;
The means for verifying is configured to periodically check and update the current connection status for all of the registered user computers, and from this update it turns out that any user status has changed online, 54. One of the claims 49 to 53, wherein the presence of a corresponding watch is confirmed from among a plurality of stored watches, and if it is found, the response means is activated to send a message corresponding to the found watch. The transmission server according to item 1. The data store is configured to store a list of registered user computers that are currently online;
55. The transmission server according to any one of claims 49 to 54, wherein the transmission server further comprises online verification means for verifying a list of currently online user computers before storing the watch in the data store.   56. The transmission server according to claim 55, further comprising transfer means for transferring the identity of the monitored user computer to the current online list when it is found from the status of the registered user computer that the registered user computer has changed to online. . A method for assisting in establishing peer-to-peer data communication, such as email communication, between a first and second user computer comprising:
Receiving a connection request from a first user computer to a locally registered second user computer;
Verifying the current connection state of the connection to the second user computer;
Storing the details of the request as a watch if it is determined from the current connection state of the second user computer that peer-to-peer communication with the second user computer cannot currently be established;
In response to the verifying step, the second user computer's online status is indicated if the status of the second user computer has changed, indicating that a peer-to-peer communication with the second user computer has now been established. Sending a message to a first user computer,
The verifying step periodically checks and updates the current connection status to the second user computer, and when this update reveals that the second user status has changed online, the presence of a corresponding watch To send a message by activating the response means if a watch is found. A secure communication, such as an email communication channel, between the first and second user computers via a data communication network where at least communication of the first user computer is handled by a first network address translator (NAT). A method for establishing a peer-to-peer data communication channel, comprising:
Requesting a direct connection between a first user computer and a transmission server via a transmission control protocol / Internet protocol (TCP / IP) communication link established by a first NAT;
Establishing a first user diagram protocol (UDP) port at the transmission server;
Reporting the address of the first UDP port to the first user computer via a TCP / IP communication link;
Opening a second UDP port of the first user computer;
Sending a data packet from the second UDP port via the first NAT to the first UDP port so that the transmission server can determine the first NAT address of the second UDP port;
Obtaining a third UDP port address of a second user computer at the transmission server;
Informing each of the first and second user computers of each other's UDP port address so that secure peer-to-peer communication can be established between the first and second user computers. And a method comprising.   59. The method of claim 58, further comprising creating a TCP / IP communication link from the first user computer to the transmission server via the first NAT.   60. The method of claim 59, wherein creating comprises searching for and identifying a local transmission server on the transmission server network to which the second user computer is registered and connecting to the local transmission server. The step of the second user computer registering with the transmission server and establishing and acquiring a TCP / IP communication link between them via the second NAT further comprises:
Establishing a fourth UDP port at the transmission server;
Reporting the address of the fourth UDP port to the second user computer via a TCP / IP communication link;
Opening a third UDP port on the second user computer;
Send a data packet from the third UDP port via the second NAT address to the fourth UDP port so that the transmission server can determine the second NAT address of the third UDP port of the second user computer. 61. A method according to any one of claims 58 to 60 comprising the steps of:   62. A method according to any one of claims 58 to 61, further comprising the first user computer switching the destination of the second UDP port from the first UDP port to the third UDP port.   64. The method of claim 62, wherein the first user computer is configured to send a peer-to-peer message directly from the second UDP port to the third UDP port of the second user computer.   64. A method according to any one of claims 58 to 63, further comprising the second user computer switching the destination of the third UDP port from the fourth UDP port to the second UDP port.   68. The method of claim 64, wherein the second user computer is configured to send a peer-to-peer message directly from the third UDP port to the second UDP port of the second user computer. Detecting inactivity of the first UDP port when peer-to-peer communication is established between the first and second user computers;
66. A method according to any one of claims 58 to 65, comprising closing the connection with the first user computer by closing the first UDP port.   68. The method of claim 66, further comprising the transmission server disconnecting the TCP / IP connection with the first user computer. Detecting inactivity of the fourth UDP port when peer-to-peer communication is established between the first and second user computers;
68. A method according to any one of claims 58 to 67, comprising closing the connection with the second user computer by closing the fourth UDP port.   69. The method of claim 68, further comprising the transmission server disconnecting the TCP / IP connection with the second user computer. The first or second NAT is an asymmetric NAT with a different UDP port for each destination;
Recording the new address of the direct connection from the asymmetric NAT;
70. The method according to any one of claims 58 to 69, comprising re-addressing the UDP port output to a new address of the asymmetric NAT. A transmission server that assists in establishing a secure peer-to-peer data communication channel, such as an e-mail communication channel, between a first and second user computers via a data communication network, wherein at least the first user computer communicates Processed by a first network address translator (NAT),
Request receiving means for receiving a request for direct connection via a transmission control protocol / Internet protocol (TCP / IP) communication link established by a first NAT between a first user computer and a transmission server;
Means for establishing a first user diagram protocol (UDP) port at the transmission server;
Reporting means for reporting the address of the first UDP port to the first user computer via a TCP / IP communication link;
Data packet receiving means for receiving a data packet sent from the second UDP port set in the first user computer to the first UDP port via the first NAT, wherein the transmission server has a second Data packet receiving means configured to determine a first NAT address of the UDP port;
Obtaining means for obtaining a third UDP port address of the second user computer in the transmission server;
A transmission server comprising means for notifying each of the first and second user computers of each other's UDP port address so that the first and second user computers can establish secure peer-to-peer communication therebetween. A method for establishing a secure pseudo peer-to-peer data communication channel, such as an electronic mail communication channel, between a first and second user computers over a data communication network, wherein communication between both user computers is first and second Processed by an asymmetric network address translator (NAT)
Creating a Transmission Control Protocol / Internet Protocol (TCP / IP) communication link from each user computer to the transmission server via respective first and second asymmetric NATs;
When receiving a direct connection request received via a TCP / IP communication link between the first user computer and the transmission server by the first NAT, the transmission server receives first and second user diagram protocols (UDP). Establishing a port;
Reporting the addresses of the first and second UDP ports to the first and second user computers, respectively, via respective TCP / IP communication links;
Opening a third UDP port on the first user computer and opening a fourth UDP port on the second user computer;
A data packet is sent from the third UDP port via the first NAT to the first UDP port and from the fourth UDP port via the second NAT to the second UDP, whereby the transmission server Enabling the determination of the first NAT address of the third UDP port and the second NAT address of the fourth UDP port;
The data packet received at the first UDP port is transferred to the NAT address of the fourth UDP port via the second UDP port, and the data packet received at the second UDP port is transferred via the first UDP port. Establishing a pseudo peer-to-peer communication between the first and second user computers by forwarding to the NAT address of the third UDP port, thereby effectively returning the data packet from the transmission server. Including methods.   73. The method of claim 72, wherein forwarding comprises storing received data packets instantaneously and temporarily prior to forwarding.   74. A method according to claim 72 or 73, wherein the generating step comprises the step of searching for and identifying a local transmission server on the transmission server network with which the second user computer is registered and connecting to the local transmission server.   75. A method according to any one of claims 72 to 74, further comprising the transmission server disconnecting the TCP / IP connection between the first and second user computers after establishing pseudo peer-to-peer communication. A transmission server that assists in establishing a secure pseudo-peer-to-peer data communication channel, such as an email communication channel, between a first and second user computers via a data communication network, wherein communication between both user computers Are handled by respective first and second asymmetric network address translators (NATs),
Means for creating a transmission control protocol / internet protocol (TCP / IP) communication link from each user computer to the transmission server via respective first and second asymmetric NATs;
When a direct connection request is received between a first user computer and a transmission server via a TCP / IP communication link by a first NAT, the transmission server receives first and second user diagram protocols (UDP). An establishment means for establishing a port;
Reporting means for reporting the addresses of the first and second UDP ports to the first and second user computers, respectively, via respective TCP / IP communication links;
The third UDP port set in the first computer is sent to the first UDP port via the first NAT, and the second NAT is sent from the fourth UDP port set in the second user computer. Data packets sent to the second UDP over the network, so that the transmission server can determine the first NAT address of the third UDP port and the second NAT address of the fourth UDP port. Means to receive and
The data packet received at the first UDP port is transferred to the NAT address of the fourth UDP port via the second UDP port, and the data packet received at the second UDP port is transferred to the first UDP port. A transmission server in which pseudo-peer-to-peer communication between the first and second user computers is established by effectively returning data packets from the transmission server. . A method for connecting a user computer to a hierarchical connection network of transmission servers to assist in establishing peer-to-peer communication over a data communication network between a sender computer and a designated recipient computer, comprising:
Receiving information indicating the current load of each of a plurality of peer forwarding servers at the same hierarchical level as the local transmission server in the connection network;
Receiving a request to connect a local user computer to a local transmission server;
Comparing the local server's current load with each of the peer servers;
If the load on the local transmission server is significantly greater than the load on any of the peer servers, sending a response to the local user computer indicating that it should connect to the peer server with the lowest load;
Accepting a connection request and updating the current load on the local transmission server if the load on the local transmission server is not significantly greater than the load on any of the peer servers.   78. The method of claim 77, wherein the current load on the transmission server is determined by the number of user computers registered with the transmission server.   79. A method according to claim 77 or 78, further comprising transferring the current load of the local transmission server to a higher level transmission server in the hierarchical network.   80. The method of claim 79, wherein the forwarding step includes sending the current IP address and port of the local transmission server.   81. A method according to claim 79 or 80, wherein the forwarding step includes sending heartbeat signals at regular intervals, wherein each heartbeat signal provides updated updated information regarding the load of the local transmission server.   82. A method according to any one of claims 77 to 81, wherein receiving comprises receiving information indicating a current IP address and port of each of a plurality of peer forwarding servers.   78. The step of receiving includes periodically receiving a heartbeat signal for each of a plurality of peer forwarding servers, wherein the heartbeat signal includes information indicating the identity of the peer forwarding server and the current load of the peer forwarding server. 83. The method according to any one of items 82 to 82.   84. A method according to any one of claims 77 to 83, further comprising determining a geographical location of the local transmission server.   85. The method of claim 84, wherein receiving comprises receiving information regarding the geographic location of each of the plurality of peer forwarding servers.   86. A method according to claim 84 or 85, wherein the geographic information includes time zone information for a local or peer forwarding server. Comparing comprises comparing the current load of the local server with each peer server in the same geographical location as the local user;
Sending to a peer transmission server in the same geographical location as the local user computer with the least load, if the load on the local transmission server is significantly greater than the load on any of the peer servers in the same geographical location 88. A method according to claim 85 or claim 86 dependent on claim 85, comprising sending a response indicating that a connection is to be made.   88. A method according to any one of claims 77 to 87, wherein the sending step comprises sending the communication address of the parent transmission server at a higher hierarchical level adjacent to the connection network for the local transmission server. Obtaining and considering the load of all child transmission servers connected to the local transmission server and at a lower level in the hierarchical connection network; and
Assessing the local server's current load by each child server;
78. sending a response to the local user computer indicating that it should connect to the child server having the lowest load if the load on the local transmission server is significantly greater than the load on any of the child servers. 90. The method according to any one of 88.   90. The method of claim 89, further comprising determining a geographic location of the local transmission server, wherein obtaining comprises receiving information regarding the geographic location of each of the plurality of child transmission servers.   The method of claim 90, wherein the geographic information includes time zone information for a local or child transmission server. The step of evaluating comprises comparing the current load of the local server with each of the child servers in the same geographical location as the local user;
The sending phase should connect to a child transmission server at the same geographical location as the local user computer with the least load if the load on the local transmission server is significantly greater than the load of any child server at the same geographical location 92. A method according to claim 90 or 91, comprising sending a response to the local user computer indicating that it is. A method of joining a node to a network of authenticated communication servers configured to be used in establishing peer-to-peer data communication between user computers registered in a communication server, comprising:
Using the user identification and password received from the authentication server to cause the authentication server to authenticate the node;
Receiving notification of the identity of a particular communication server to which the node must connect in order to join the network;
Requesting data specific to a specific communication server and node from the authentication server to connect to the specific communication server;
Receiving data specific to a particular communication server and node and a shared encryption key shared by the node and the particular communication server;
Data specific to a specific communication server and node and global data encrypted with an encryption key are sent to the specific communication server, so that the specific communication server authenticates the node to the network and thereby from the authentication server. Having a tool that joins the network without asking for verification.   94. The method of claim 93, further comprising receiving confirmation data encrypted with a shared encryption key from a particular communication server such that the node has information to verify the authenticity of the particular communication server.   95. The method of claim 93 or 94, further comprising obtaining a user ID and password by registering the node with an authentication server of the network.   96. A method according to any one of claims 93 to 95, wherein receiving the notification comprises accepting a ticket generation ticket used in the requesting step.   99. The method of claim 96, wherein receiving the notification comprises obtaining a session key for the node used in the receiving step.   98. A method according to any one of claims 93 to 97, wherein the ticket generation ticket and the session key are encrypted with a password, further comprising decrypting the ticket generation ticket and the session key.   99. A method according to any one of claims 96 to 98, wherein the requesting step includes the step of sending a ticket generation ticket and an identification of a particular communication server to an authentication server.   99. A method according to any one of claims 93 to 99, wherein the receiving comprises obtaining a ticket specific to a particular communication server and node.   101. The method of claim 100, wherein the ticket includes a copy of the shared encryption key.   102. The method of claim 101, further comprising decrypting a shared key encrypted with a session key.   103. The method according to any one of claims 93 to 102, further comprising calculating a timestamp value as global data.   104. A method according to any one of claims 93 to 103, further comprising the step of a particular communications server decrypting the received data using a shared key.   105. A method according to any one of claims 93 to 104, further comprising the step of a particular communication server verifying the validity of the received data.   106. The method of claim 104 or 105, further comprising the specific communication server sending a confirmation that the decrypted received data is acceptable.   107. A method according to any one of claims 93 to 106, further comprising receiving authentication data modified in a predetermined manner.   108. The method of claim 107, further comprising the step of encrypting the modified authentication information and decrypting the modified authentication information. Securely with a second user computer that is part of a network of authenticated communication servers configured to be used to establish peer-to-peer data communication between user computers registered with the communication server A method of communicating,
Coupling a first computer to a network as described in any one of claims 1 to 16;
Creating public and private keys on the first and second user computers;
Exchanging a public key between the first and second user computers via a network;
Creating a shared encryption / decryption key from the non-shared secret key and the shared public key at each of the first and second user computers;
Encrypting a data message sent directly between the first and second user computers via a peer-to-peer connection between the first and second user computers using a shared encryption key. A method of connecting a first hierarchical realm of interconnected transmission server nodes to a second hierarchical realm of interconnected transmission server nodes, comprising:
Providing a local authentication server within each realm that is connected to the primary node at the highest level of each hierarchical realm to control authentication issues associated with all servers in the realm A stage composed of:
Registering the primary node of the first hierarchy realm with the authentication server of the second hierarchy realm;
Authenticating the primary node of the first hierarchy realm against the authentication server of the second hierarchy realm;
Receiving notification regarding the identification of the lowest node server to which the primary node of the first hierarchy realm must connect in order to join the hierarchy realms;
Receiving shared data and a shared encryption key of both the lowest node server of the second hierarchy realm and the primary node of the first hierarchy realm;
Using the received shared data and shared encryption key, the primary node of the first hierarchy realm is authenticated to the lowest node server of the second hierarchy realm, thereby verifying from the authentication server of the second realm Combining the first and second realms without asking.   Requesting data specific to the primary node of the first realm and the lowest node server of the second realm from the authentication server to connect to a particular lowest node server of the second realm. 111. The method of claim 110.   Sending the shared data and the global data encrypted by the shared encryption key to the lowest node server such that the lowest server has a tool to authenticate the primary node to the second hierarchy realm. 112. The method of claim 110 or 111, comprising.   113. A method according to any one of claims 110 to 112, wherein the authentication step is performed via the lowest node server of the second tier realm. Registering the primary node of the second hierarchy realm with the authentication server of the first hierarchy realm;
114. The method of any one of claims 110 to 113, comprising authenticating a primary node of the second hierarchy realm against an authentication server of the first hierarchy realm. A second realm of a transmission server configured to be used when a first user computer connected to the first realm of the transmission server establishes peer-to-peer data communication between user computers registered in the communication server A method of securely communicating with a second user computer connected to
Connecting the first user computer of the first realm to the second realm of the transmission server according to any one of claims 110 to 114;
Determining a network location within the interconnected realm for the first and second user computers;
Establishing a peer-to-peer communication channel between the first and second user computers using the established network location;
Sending encrypted data communication over an established peer-to-peer communication channel. The stage to use is
Creating a public key and a private key on the first and second user computers;
Exchanging public keys between the first and second user computers over a network;
Creating a shared encryption / decryption key from the non-shared secret key and the shared public key at each of the first and second user computers;
Encrypting a data message transmitted directly between the first and second user computers via a peer-to-peer connection established between the first and second user computers using a shared encryption key. 116. The method of claim 115.

Images