Session key distribution methods using a hierarchy of key servers

CROSS-REFERENCE TO RELATED APPLICATIONS

0001This application claims the benefit of priority from U.S. patent application Ser. No. 60/364,621 filed Mar. 18, 2002.

BACKGROUND OF THE INVENTION

00021. Field of Invention

0003The present invention relates to communications, and more particularly, to methods, apparatuses, media, signals and computer program products for facilitating secure communications between a first device and a second device:

00042. Description of Related Art

0005It is often desirable to have secure communications between first and second devices. For example, the devices may include respective desktop, laptop or handheld computers, in communication with each other over a public network such as the Internet. It is frequently desirable to allow these devices to transmit sensitive information securely to one another over the Internet, without significant risk of interception by unauthorized eavesdroppers. In many instances, it is desirable to attempt to arrange secure communication between the first and second devices, even if the first and second devices have never previously communicated with each other before. For example, a patent attorney or other lawyer may wish to communicate sensitive secret client information to a new client over the Internet, but may wish to minimize the risk of unauthorized interception of such information. Or, as a further example, a purchaser may wish to transmit sensitive payment account information such as credit card information to a vendor over the Internet.

0006Numerous conventional secure communications methods exist. The methods that are most commonly used over the Internet at present (such as SSL) employ an infrastructure based upon asymmetric encryption. In asymmetric encryption, two keys are used: a private key that is kept secret or private, and a public key that is accessible by every computer on the Internet. However, the current asymmetric encryption methods (as do any other secure communications methods) have potential inherent security risks that may be exploitable. Such risks may be partly addressed by symmetrical encryption methods, wherein only a single symmetrical key (referred to herein as a private key) is used, and key distribution schemes are adopted to attempt to securely provide the private key to the parties that wish to communicate.

0007A number of key distribution schemes have been proposed to attempt to provide two users or clients with a private key for communication therebetween. However, these schemes tend to presume that both of the two clients already have pre-existing relationships with the same trusted intermediary server, and have previously exchanged mutual keys with the server to allow them to establish secure communications with the trusted intermediary server. Such schemes also tend to presume that each of the two users is also aware that both users have pre-existing relationships with the trusted intermediary, and that the trusted intermediary in question is therefore a suitable server to select for execution of the key distribution scheme. In many cases, however, particularly where two users are in communication with each other via a large public wide area network such as the Internet, neither of the two users will have any knowledge of the other's pre-existing relationships with key servers, and indeed, many unsophisticated computer users may not have any knowledge of their own pre-existing relationships with key servers. Thus, even if a trusted intermediary with pre-existing relationships with both users exists, the users may not be aware of this fact and may not know to select the trusted intermediary for this purpose. In addition, in many cases the group of key servers with which one user has pre-existing relationships will not include any of the key servers with which the other user has pre-existing relationships, with the result that a trusted intermediary is not available to participate in the key distribution scheme. These problems would tend to arise unless mutual keys had been pre-established at both a client-server level and a server-server level over all domains, which would not be practical for a large network such as the Internet that includes a very large number of domains.

0008Accordingly, there is a need for an improved secure communications method.

SUMMARY OF THE INVENTION

0009In accordance with another aspect of the invention, there is provided a method of facilitating secure communication between first and second devices. The method includes automatically identifying a common key server potentially accessible by both the first and second devices, and obtaining a secure private key from the common key server, for use in encrypting communications between the first and second devices.

0010Advantageously, as the method includes automatically identifying a common key server potentially accessible by both the first and second devices, it is not necessary for the first and second devices to know the identity of the common key server in advance, nor is it necessary for them to have previously exchanged mutual keys with the common key server. It is sufficient for the first and second devices to know that they wish to communicate securely with each other, and for each of the devices to have a parent key server (not necessarily the same key server). In addition, as a private key is obtained for encryption purposes, the method is not susceptible to potentially exploitable security weaknesses associated with asymmetric encryption.

0011Identifying the common key server may include transmitting identifications of key servers from one of the first and second devices to the other of the first and second devices. Identifying may further include producing a first list of key servers potentially accessible by the first device.

0012Producing may include including in the first list, identifications of key servers associated with first device keys stored in a storage medium of the first device. Producing may further include including in the first list, identifications of intermediate key servers interposed along secure communications paths between each of the key servers associated with the first device keys and a master key server.

0013Transmitting may include transmitting the first list from the first device to the second device. Identifying may further include receiving at the first device, from the second device, an identification of the common key server.

0014Identifying may include receiving at the second device, a first list of key servers potentially accessible by the first device. Identifying may further include producing a second list of key servers potentially accessible by the second device. Producing may include including in the second list, identifications of key servers associated with second device keys stored in a storage medium of the second device. Producing may further include including in the second list, identifications of intermediate key servers interposed along secure communications paths between each of the key servers associated with the second device keys and a master key server.

0015Identifying may further include comparing the first and second lists, and identifying, as the common key server, a key server identified in both lists.

0016Identifying may include identifying as the common key server, from among a group of key servers each of which is identified in both the first and second lists, the key server having the shortest communications paths to the first and second devices. Advantageously therefore, in such embodiments, the time required to obtain the private key is potentially reduced in comparison to systems that always rely on a single key server.

0017Identifying may include identifying as the common key server, a key server at an intersection of a first communication path defined between a first key server having a previously established relationship with the first device and a master key server, and a second communication path defined between a second key server having a previously established relationship with the second device and the master key server. Advantageously therefore, in such embodiments, it is not necessary for the first and second devices to have a previously-established relationship with the same, single trusted intermediary in order to establish secure communications between themselves.

0018Transmitting may include transmitting, from the second device to the first device, an identification of the common key server. Transmitting may further include transmitting, from the second device to the first device, identifications of any intermediate key servers interposed between the first device and the common key server.

0019Identifying may further include identifying intermediate key servers interposed along a communications path between one of the first and second devices and the common key server. Obtaining may include obtaining the private key from one of the intermediate key servers that has received the private key from the common key server.

0020Obtaining may include receiving the private key from the common key server via a secure communications channel. Receiving may include receiving the private key from an intermediate key server that has received the private key from the common key server.

0021Obtaining may further include transmitting a request message to the common key server to request the common key server to transmit the private key. Transmitting may include transmitting the request message to an intermediate key server, for relay to the common key server.

0022The method may further include validating the private key. Validating may include receiving a first hash value produced by the common key server in response to the private key, generating a second hash value in response to the received private key, and comparing the first and second hash values.

0023Obtaining may include obtaining first and second private keys from at least one of the common key server and a second common key server potentially accessible by both the first and second devices. Obtaining first and second private keys may include obtaining a private user key from a common user key server and a private device key from a common device key server.

0024The method may further include obtaining an initial session key. Obtaining the initial session key may include receiving the initial session key at the first device. Alternatively, from the perspective of the second device, obtaining the initial session key may include generating the initial session key at the second device and transmitting the initial session key to the first device.

0025The method may further include encrypting communications between the first and second devices, in response to the private key. In embodiments where first and second private keys are received, this may include encrypting communications between the first and second devices, in response to the first and second private keys. Similarly, in embodiments where an initial session key is additionally received, this may include encrypting communications between the first and second devices, in response to the first and second private keys and the initial session key. Encrypting may include blending the first and second private keys and the initial session key to produce a modified key.

0026Blending may include encrypting at least one of the first and second private keys and the initial session key using at least one other of the first and second private keys and the initial session key. For example, blending may include encrypting the first private key using the second private key to produce a once-encrypted key. Similarly, blending may further include encrypting the once-encrypted key using the initial session key to produce a twice-encrypted key. Blending may further include generating a hash value in response to the twice-encrypted key, and appending the hash value to the twice-encrypted key. Blending may further include deleting a portion of the twice-encrypted key other than the hash value appended thereto, the deleted portion having a length equal to the hash value appended thereto. Blending may further include repeating the steps of generating and appending a hash value to the twice-encrypted key and deleting a portion of the twice-encrypted key until the twice-encrypted key has been entirely replaced with appended hash values. Advantageously, in such embodiments, the final private session key so generated is a truly private key, with no corresponding root keys stored in a software program or on the device or on a publicly accessible key server. As the final private session key has not been directly transmitted over the Internet (or other network) at all, and no devices other than the first and second devices have all the data necessary to create the final private session key, security is considerably enhanced as compared to conventional secure communications systems.

0027More generally, if desired, encrypting may include encrypting communications between the first and second devices using a blended key produced in response to the private key.

0028Encrypting may include initiating a cipher communications session with the blended key. Initiating may include executing a modified ARC4 streaming cipher communications session. Executing may include repeating a shuffling loop of the ARC4 streaming cipher communications session, a prime number of times greater than two.

0029In accordance with another aspect of the invention, there is provided an apparatus for facilitating secure communication between first and second devices. The apparatus includes a processor circuit capable of communication with a network. The processor circuit is configured to identify a common key server potentially accessible by both the first and second devices. The processor circuit is also configured to obtain a secure private key from the common key server, for use in encrypting communications between the first and second devices.

0030The processor circuit may be configured to carry out the various methods disclosed herein.

0031In accordance with another aspect of the invention, there is provided an apparatus for facilitating secure communication between first and second devices. The apparatus includes means for identifying a common key server potentially accessible by both the first and second devices. The apparatus further includes means for obtaining a secure private key from the common key server, for use in encrypting communications between the first and second devices.

0032The apparatus may further include means for performing the various functions disclosed herein.

0033In accordance with another aspect of the invention, there is provided a method of facilitating secure communications between first and second devices. The method includes receiving, at an intermediate key server, a request message from one of the first and second devices requesting a private key. The method further includes relaying the request message to a common key server potentially accessible by both the first and second devices. Similarly, in accordance with another aspect of the invention, there is provided an apparatus for facilitating secure communications between first and second devices. The apparatus includes an intermediate key server, including a processor circuit configured to carry out the above method. In accordance with another aspect of the invention, there is provided an apparatus including an intermediate key server. The intermediate key server includes means for performing the above functions.

0034In accordance with another aspect of the invention, there is provided a method of facilitating secure communications between first and second devices. The method includes receiving, at a common key server potentially accessible by both the first and second devices, request messages from first and second intermediate servers interposed between the common key server and the first and second devices respectively, requesting a private key. The method further includes generating and transmitting the private key to the first and second intermediate servers in response to the request messages, for relay to the first and second devices. Similarly, in accordance with another aspect of the invention, there is provided an apparatus for facilitating secure communications between first and second devices. The apparatus includes a common key server potentially accessible by both the first and second devices. The common key server includes a processor circuit configured to carry out the above method. In accordance with another aspect of the invention, there is provided an apparatus including a common key server potentially accessible by both the first and second devices. The common key server includes means for performing each of the above functions.

0035In accordance with another aspect of the invention, there is provided a computer program including code means that when executed on a computer carry out all the steps of any of the methods disclosed herein. Similarly, in accordance with another aspect of the invention, there is provided a computer program on a carrier carrying codes that when executed on a computer carry out all the steps of any of the methods disclosed herein. In accordance with another aspect of the invention, there is provided a computer-readable medium storing code segments for directing a processor circuit to carry out any of the methods disclosed herein. In accordance with another aspect of the invention, there is provided a signal embodied in a communications medium, the signal including code segments for directing a processor circuit to carry out any of the methods disclosed herein. In accordance with another aspect of the invention, there is provided a signal embodied in a carrier wave, the signal including code segments for directing a processor circuit to carry out any of the methods disclosed herein.

0036Other aspects and features of the present invention will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments of the invention in conjunction with the accompanying figures.

BRIEF DESCRIPTION OF THE DRAWINGS

0037In drawings which illustrate embodiments of the invention,

0038<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram of a public network in which a plurality of user devices is in communication with a plurality of key servers;

0039<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram of an apparatus for facilitating secure communication between first and second devices shown in <figref idref="DRAWINGS">FIG. 1</figref>, according to a first embodiment of the invention;

0040<figref idref="DRAWINGS">FIG. 3</figref> is a signal flow diagram illustrating signal flow among the devices and servers shown in <figref idref="DRAWINGS">FIG. 1</figref>;

0041<figref idref="DRAWINGS">FIGS. 4A-4B</figref> are a flowchart of a messaging thread executed by a processor circuit of the apparatus shown in <figref idref="DRAWINGS">FIG. 2</figref>; and

0042<figref idref="DRAWINGS">FIGS. 5-11</figref> are tabular representations of various signals shown in <figref idref="DRAWINGS">FIG. 3</figref>.

DETAILED DESCRIPTION

0043Referring to <figref idref="DRAWINGS">FIG. 1</figref>, an apparatus for facilitating secure communication between first and second devices according to a first embodiment of the invention is shown generally at <b>20</b>. In this embodiment, the apparatus <b>20</b> includes a processor circuit <b>50</b> capable of communication with a network. The processor circuit is configured to identify a common key server <b>32</b> potentially accessible by both a first device <b>26</b> and a second device <b>28</b>. The processor circuit <b>50</b> is configured to obtain a secure private key from the common key server <b>32</b>, for use in encrypting communications between the first and second devices <b>26</b> and <b>28</b>. In this embodiment, the term “accessible” does not require direct accessibility, but can also include indirect accessibility, and therefore does not imply the necessity of any previously established direct relationship between the first device and the common key server, nor between the second device and the common key server.

0044In this embodiment, the processor circuit <b>50</b> is housed within the first device <b>26</b>. In the present embodiment, the second device <b>28</b> also includes a processor circuit <b>51</b> similar to the processor circuit <b>50</b>. Like the processor circuit <b>50</b> of the first device <b>26</b>, the processor circuit <b>51</b> of the second device <b>28</b> is also configured to identify the common key server potentially accessible by both devices, and to obtain a secure private key from the common key server for use in encrypting communications.

0045Referring to <figref idref="DRAWINGS">FIGS. 1 and 2</figref>, in this embodiment, the first and second devices <b>26</b> and <b>28</b> are merely two illustrative examples of a larger plurality of user devices <b>24</b>. Each of the plurality of user devices <b>24</b> is capable of communication with each other and with one or more of a plurality of key servers shown generally at <b>22</b> via a public network <b>44</b>, which in this embodiment includes the Internet.

0046In the present embodiment, the first device <b>26</b> and the second device <b>28</b> include respective desktop computers. Alternatively, however, the first and second devices may include personal communication devices. For example, the first and second devices may include personal computing devices, such as desktop or laptop computers, or may include handheld computing devices such as handheld computers or e-mail devices, for example. Alternatively, however, the first and second devices need not include user or client devices, but may alternatively include other devices such as servers, for example, or more generally, may include any other suitable type of communications devices.

0047In this embodiment, the first and second devices <b>26</b> and <b>28</b> wish to establish a secure communication connection therebetween, but have not securely communicated with one another previously, and neither device has any advance knowledge of the identities of any key servers that may be available to the other device. More particularly, the first and second devices <b>26</b> and <b>28</b> wish to establish a direct communications connection that does not suffer from security weaknesses associated with conventional secure communications methods, for transmission of particularly sensitive information therebetween. Alternatively, however, the present embodiment may be used equally well between devices that have securely communicated in the past.

0048In this embodiment, the key servers <b>22</b> may include any suitable computing devices capable of executing key server functionality, such as general-purpose or specialized-purpose desktop computers, for example.

0049In the present embodiment, the key servers <b>22</b> include a master key server <b>30</b>, which is capable of secure communications with every other one of the key servers <b>22</b>, either directly, or indirectly via one or more separate secure connections with one or more intermediate key servers. Thus, in the illustrative example shown in <figref idref="DRAWINGS">FIG. 1</figref>, the key servers <b>22</b> further include a plurality of intermediate key servers, such as key servers <b>32</b>, <b>33</b> and <b>34</b> for example, and a plurality of further key servers, such as key servers <b>36</b>, <b>37</b>, <b>38</b>, <b>39</b>, <b>40</b>, <b>41</b> and <b>42</b> shown in <figref idref="DRAWINGS">FIG. 1</figref>. Alternatively, it will be appreciated that virtually any number or relative configuration of key servers may be substituted. For example, any key server in the key server “tree” shown in <figref idref="DRAWINGS">FIG. 1</figref> may act as a “parent” server to any other key server on the tree. Similarly, it will be appreciated that a much larger number of key servers, including a much larger number of intermediate key servers between each of the first and second devices <b>26</b> and <b>28</b> and the master key server <b>30</b>, may be present in a particular embodiment, for example.

0050In this embodiment, each one of the first and second devices <b>26</b> and <b>28</b> has a previously defined relationship with at least one of the key servers <b>22</b>, which has previously issued a key to the device and thus acts as a “parent” key server for the device.

0051More particularly, in the illustrative example shown in <figref idref="DRAWINGS">FIG. 1</figref>, each of the key servers <b>36</b> and <b>39</b> acts as a “parent” key server for the first device <b>26</b>, and each of the key servers <b>38</b> and <b>42</b> acts as a “parent” key server for the second device <b>28</b>. Thus, in the present embodiment, it assumed that none of the key servers <b>22</b> acts as a “parent” to both the first and second devices, or in other words, there is no shared key server with which both the first and second devices both have previously-defined relationships. In other words, in contrast with conventional private key distribution schemes, in the present embodiment it is assumed that there is no single key server with which both the first and second devices have previously established respective key pairs, to allow each of them to securely communicate with the key server. Alternatively, however, the present embodiment of the invention may also be applied to situations where such a shared key server exists.

0052Similarly, in the present embodiment, the key server <b>32</b> acts as a “parent” to key servers <b>36</b>, <b>37</b> and <b>38</b>, the key server <b>33</b> acts as a “parent” to key servers <b>39</b> and <b>40</b>, and the key server <b>34</b> acts as a “parent” to key servers <b>41</b> and <b>42</b>. For illustrative purposes, the key servers <b>32</b>, <b>33</b> and <b>34</b> are therefore referred to as “grandparent” key servers from the perspective of the first and second devices <b>26</b> and <b>28</b>. The master key server <b>30</b> acts as a parent to key servers <b>32</b>, <b>33</b> and <b>34</b>.

0053In this embodiment, each of the key servers <b>22</b> and the first and second devices <b>26</b> and <b>28</b> is capable of establishing a secure communication connection with its own immediate “parent” server, with which it has previously established secure communications. For example, in this embodiment, it is assumed that each device or server was previously assigned a user-ID and password to initially communicate with its own immediate parent. During this initial communication between each device or server and its parent key server, a hash value of the password is used as a session key, to allow the parent to securely transmit a private key to the “child” device or server. Once the private key has been initially securely transmitted, the device or server may securely communicate with its parent server using the encryption methods described herein, but without the necessity of obtaining a new private key as described below in connection with <figref idref="DRAWINGS">FIG. 3</figref>. Also during the initial communication between each device or server and its immediate parent key server, the device or server requests its immediate parent to transmit key server path information identifying the path from the immediate parent key server to the master key server <b>30</b>. For example, during the initial communication between the first device <b>26</b> and the parent key server <b>39</b>, the parent key server <b>39</b> transmits path information to the first device <b>26</b>, identifying the parent key server <b>39</b>, the grandparent key server <b>33</b>, and the master key server <b>30</b>. Upon receiving this information from the key server <b>39</b>, the first device <b>26</b> stores the received path information locally in a hard disk drive or other storage medium thereof, in association with the private key received from the parent key server <b>39</b>, for future use as described herein. Similarly, during its initial communication with the parent key server <b>36</b>, the first device <b>26</b> receives and stores path information identifying the parent key server <b>36</b>, the closest common key server <b>32</b>, and the master key server <b>30</b>, and stores such information locally in association with a key associated with the key server <b>36</b>. Likewise, the second device <b>28</b>, during its initial communication with the parent key server <b>42</b>, receives and stores path information identifying the parent key server <b>42</b>, the grandparent key server <b>34</b>, and the master key server <b>30</b>, and stores this information locally in association with the key received from the parent key server <b>42</b>. Also in this embodiment, during its initial communication with the parent key server <b>38</b>, the second device <b>28</b> receives and stores path information identifying the parent key server <b>38</b>, the closest common key server <b>32</b>, and the master key server <b>30</b>, and stores this path information locally in association with a key received from the key server <b>38</b>. It is assumed that each of the parent key servers <b>36</b> through <b>42</b> has previously received and locally stored its own upstream path information leading to the master server <b>30</b>, during its own initial communication with its immediate parent server (such as the grandparent servers <b>33</b> and <b>34</b> or the common key server <b>32</b>).

0054Referring to <figref idref="DRAWINGS">FIGS. 1 and 2</figref>, the processor circuit of the first device <b>26</b> is shown generally at <b>50</b> in <figref idref="DRAWINGS">FIG. 2</figref>. In the present embodiment, the first and second devices <b>26</b> and <b>28</b> are identical, and thus the processor circuit <b>51</b> of the second device <b>28</b> is identical to the processor circuit <b>50</b> of the first device <b>26</b> shown in <figref idref="DRAWINGS">FIG. 2</figref>. Thus, for ease of illustration, only the processor circuit <b>50</b> is described in detail, it being understood that the processor circuit <b>51</b> includes similar structural and functional features. Alternatively, as noted above, the first and second devices may include different types of devices if desired.

0055Similarly, in this embodiment, each of the key servers <b>22</b> shown in <figref idref="DRAWINGS">FIG. 1</figref> has a processor circuit similar to the processor circuit <b>50</b>, such as a processor circuit <b>132</b> of the common key server <b>32</b>, a processor circuit <b>136</b> of the key server <b>36</b>, and a processor circuit <b>138</b> of the key server <b>38</b>, for example. If desired, these processor circuits may also be capable of the full functionality of the processor circuit <b>50</b> described below. Alternatively, however, as will be apparent, for the purposes of the present embodiment of the invention, the key servers <b>22</b> do not require the full range of functionality provided by the secure communications routine <b>62</b>, but rather, may be provided with an alternative routine to merely direct their respective processor circuits to receive and respond to signals as discussed below.

0056In this embodiment, the processor circuit <b>50</b> includes a microprocessor <b>52</b>. More generally, however, in this specification, the term “processor circuit” is intended to broadly encompass any type of device or combination of devices capable of performing the functions described herein, including (without limitation) other types of microprocessors, microcontrollers, other integrated circuits, other types of circuits or combinations of circuits, logic gates or gate arrays, or programmable devices of any sort, for example, either alone or in combination with other such devices located at the same location or remotely from each other, for example. Additional types of processor circuits will be apparent to those ordinarily skilled in the art upon review of this specification, and substitution of any such other types of processor circuits is considered not to depart from the scope of the present invention as defined by the claims appended hereto.

0057In the present embodiment, the microprocessor <b>52</b> is in communication with a first computer readable medium, which in this embodiment includes a hard disk drive <b>54</b>. The microprocessor <b>52</b> is in further communication with a second computer readable medium, which in this embodiment includes a random access memory (RAM) <b>56</b>. The microprocessor <b>52</b> is in further communication with an input/output (I/O) interface <b>58</b>, through which the microprocessor communicates with the various key servers <b>22</b> and other user devices <b>24</b>, via the public network <b>44</b>. Also in this embodiment, the microprocessor <b>52</b> is in communication with a media interface device <b>53</b>, to allow the microprocessor <b>52</b> to read data from or write data to other types of computer readable media, such as a compact disc <b>55</b> or a floppy diskette <b>57</b>, for example. If desired, the microprocessor may be in further communication with other types of computer readable media, such as magnetic disks or diskettes, optical storage devices, magnetic tapes, random access memories (RAMs), programmable read-only memories such as EPROMs, EEPROMs or FLASH memories, for example, or any other type of memory device, either at the location of the processor circuit or located remotely therefrom, for example.

0058In this embodiment, the hard disk drive <b>54</b> acts as a program memory for storing various routines executable by the processor circuit <b>50</b>. Alternatively, however, it will be appreciated that the hard disk drive <b>54</b> is merely one example of a computer-readable medium for storing such routines. More generally, any other suitable type of medium, such as those noted above or others for example, or any other suitable way of generating a signal such as that shown at <b>59</b> including code segments for directing the microprocessor <b>52</b> to carry out the functions described herein, may be substituted. Such a signal may be embodied in a communications medium, such as a data bus or other link to the network <b>44</b>, or a carrier wave for example, and thus, the routines may be provided as downloaded applets or other executable instructions received from a remote source, if desired.

0059In the present embodiment, the routines stored on the hard disk drive <b>54</b> executable by the processor circuit <b>50</b> include an operating system <b>60</b>, a secure communications routine <b>62</b>, and various user applications <b>64</b>. In this embodiment, the secure communications routine <b>62</b> includes a dynamic link library for directing the processor circuit to execute a number of threads, including a messaging thread <b>66</b>, an encryption/decryption thread <b>68</b>, a pipe control/TCP send thread <b>70</b>, a TCP receive thread <b>72</b>, a key server thread <b>74</b>, and a data object monitor thread <b>76</b>. If desired, multiple instances of such threads may be defined and executed by the processor circuit. In this embodiment, the secure communications routine <b>62</b> further includes a threadsafe function <b>80</b> that the processor circuit may invoke under the direction of any of the various threads, to ensure proper handling of shared data space such as shared data buffers or registers and fields therein, for example.

0060When executed by the processor circuit <b>50</b>, the secure communications routine <b>62</b> configures or programs the processor circuit to define various registers in the RAM <b>56</b>, including a user-ID list register <b>90</b>, a device-ID list register <b>92</b>, a user-ID paths register <b>94</b>, a device-ID paths register <b>96</b>, an initial session key register <b>98</b>, a private keys register <b>100</b>, a blended key register <b>102</b>, and a final private session key register <b>104</b>. Similarly, the secure communications routine <b>62</b> configures the processor circuit to define various buffers for use in secure encrypted communications, including a send buffer <b>110</b>, a key send buffer <b>112</b>, a pipe send buffer <b>114</b>, a pipeline control buffer <b>116</b>, a key receive buffer <b>120</b>, and a receive buffer <b>122</b>.

0061It will be appreciated that numerous other registers and buffers may similarly be defined and used by the processor circuit under the direction of the secure communications routine <b>62</b>.

0062In this embodiment, the user applications <b>64</b> do not interface directly with the TCP/IP functionality of the operating system <b>60</b>. Rather, the user applications <b>64</b> interface with the secure communications routine <b>62</b>, which establishes and handles all TCP/IP communications. To facilitate this interface with the user applications <b>64</b>, in the present embodiment the secure communications routine <b>62</b> is provided in the form of a dynamic link library (.dll) file, which in this embodiment requires approximately <b>150</b> kB of storage space in the hard disk drive <b>54</b>. In this embodiment, although the secure communications routine <b>62</b> is described below as having a single set of threads for illustrative purposes, more generally, the secure communications routine <b>62</b> of the present embodiment is multithreaded. For example, if a particular user application creates a plurality of client objects, each client object will have its own corresponding set of threads for its own respective secure communications session. Similarly, if the first device is acting as a server, with a plurality of connected clients, a separate set of threads will be executed for each client. All such multithreading occurs transparently to the user application, which need not be multithreaded itself, and need not synchronize the various sets of threads.

0063In a particular embodiment, if the operating system <b>60</b> includes a Windows operating system, it may be preferable for Windows Message Notificafion for TCP to be deactivated. In a Windows environment, the send and receive operations of TCP are preferably in endless loops, and exit only if the communications session collapses. Other potential exit triggers, such as timeouts, are preferably disabled, as some timeouts may occur in certain embodiments if particular buffers temporarily fill.

0000Messaging Thread

0064Referring to FIGS. <b>1</b> to <b>11</b>, the messaging thread is shown generally at <b>66</b> in <figref idref="DRAWINGS">FIGS. 4A-4B</figref>. Generally, the messaging thread <b>66</b> configures or programs the processor circuit <b>50</b> to automatically identify a common key server potentially accessible by both the first and second devices <b>26</b> and <b>28</b>, and to obtain a secure private key from the common key server, for use in encrypting communications between the first and second devices.

0065In the present embodiment, to identify the common key server and obtain the secure private key, the messaging thread <b>66</b> configures the processor circuit <b>50</b> to participate in a signal flow shown generally at <b>500</b> in <figref idref="DRAWINGS">FIG. 3</figref>.

0066Referring to FIGS. <b>1</b> to <b>4</b>B, the messaging thread <b>66</b> begins with a first block <b>200</b> of codes shown in <figref idref="DRAWINGS">FIG. 4A</figref>, which directs the processor circuit <b>50</b> of the first device <b>26</b> to determine whether one of the user applications <b>64</b> being executed by the processor circuit <b>50</b> has requested the messaging thread <b>66</b> to initiate secure communications with another device, which is assumed for illustrative purposes to be the second device <b>28</b>. If so, the processor circuit <b>50</b> is directed to execute blocks <b>202</b> to <b>208</b>. If no such request to initiate communications has been received, the processor circuit is directed to determine whether a request for secure communications has been received from the second device <b>28</b> at the first device <b>26</b>. If so, the processor circuit is directed to execute blocks <b>212</b> through <b>222</b>.

0067In the present description of the messaging thread <b>66</b>, for illustrative purposes, it is assumed that the first device <b>26</b> initiates communications with the second device <b>28</b>, and thus the processor circuit <b>50</b> of the first device executes blocks <b>202</b> to <b>208</b> in <figref idref="DRAWINGS">FIG. 4A</figref>. Therefore, it is assumed that the second device <b>28</b> responds to the communications initiation request, and that the processor circuit <b>51</b> of the second device executes blocks <b>212</b> through <b>222</b>. Alternatively, however, the second device <b>28</b> may initiate communications if desired, in which case the processor circuit <b>51</b> may execute blocks <b>202</b> to <b>208</b> and the processor circuit <b>50</b> may execute blocks <b>212</b> through <b>222</b>. For illustrative purposes only, in the following description, the term “first device” is used to indicate the device initiating communications, and the term “second device” is used to indicate the device responding to the communications initiation request.

0068Accordingly, in the present illustrative example, to initiate secure communications between the first device <b>26</b> and the second device <b>28</b>, blocks <b>202</b> to <b>206</b> of the messaging thread <b>66</b> direct the processor circuit <b>50</b> to transmit identifications of key servers from the first device to the second device. More particularly, blocks <b>202</b> and <b>204</b> direct the processor circuit <b>50</b> to produce a first list of key servers potentially accessible by the first device. Blocks <b>202</b> and <b>204</b> direct the processor circuit <b>50</b> to include in the first list, identifications of key servers associated with first device keys stored in a storage medium of the first device. More particularly still, in this embodiment block <b>202</b> directs the processor circuit <b>50</b> to examine the contents of the hard disk drive <b>54</b>, and identify all device keys (associated with the particular device <b>26</b>, regardless of the user using the device) and user keys (associated with the user of the device <b>26</b>, no matter what device the user is using) used by the first device <b>26</b>. Block <b>204</b> directs the processor circuit <b>50</b> to produce and store a user-ID list and a device-ID list, in the user-ID list register <b>90</b> and the device-ID list register <b>92</b>, respectively, each list including a server path for each identified user or device key, respectively.

0069Referring to <figref idref="DRAWINGS">FIGS. 1, 2</figref>, <b>4</b>A and <b>5</b>, in this embodiment, block <b>204</b> further configures the processor circuit <b>50</b> to include in the first list, identifications of intermediate key servers interposed along secure communications paths between each of the key servers associated with the first device keys and a master key server. This is performed for each of the user-ID list and the device-ID list. More particularly, in this embodiment the processor circuit <b>50</b> is directed to store, in the user-ID list register <b>90</b>, a first user-ID path <b>502</b> representing a server path corresponding to a default or preferred user-ID, and a plurality of additional or alternative user-ID paths <b>504</b>. Each of the server paths <b>502</b> and <b>504</b> includes a name field <b>506</b> for storing a user name, a first “parent” key server field <b>508</b> for storing an identification of a first key server associated with the key, and a plurality of further key server fields <b>510</b>, for storing identifications of all intervening key servers along a secure path leading to and including the master key server <b>30</b> shown in <figref idref="DRAWINGS">FIG. 1</figref>. For example, in the example shown in <figref idref="DRAWINGS">FIG. 1</figref>, the first device <b>26</b> uses a user-ID key associated with the key server <b>36</b>, and thus, the relevant user-ID list entry includes a user name corresponding to the key, an identification of the key server <b>36</b>, an identification of the common key server <b>32</b>, and an identification of the master key server <b>30</b>. In this regard, it will be recalled that during its prior initial communication with the key server <b>36</b> in which it obtained the user-ID key, the first device <b>26</b> will have received and locally stored path information identifying the key server path from the key server <b>36</b> to the master key server <b>30</b>, which in this example includes identifications of the key server <b>36</b>, an intermediate server, namely, the closest common key server <b>32</b>, and the master key server <b>30</b> itself. In the present embodiment, during such prior initial communication with the key server <b>36</b>, the first device receives and stores such information locally, in the hard disk drive <b>54</b>, in association with the user-ID key associated with the key server <b>36</b>. Thus, block <b>204</b> directs the processor circuit <b>50</b> to locate such path information stored in the hard disk drive <b>54</b> in association with the relevant user-ID key, and to copy the identifications of the key servers identified in the stored path information into the appropriate fields <b>508</b> and <b>510</b> of the relevant record in the user-ID list register <b>90</b> corresponding to the particular user-ID key. Alternatively, if desired, rather than relying upon the previously locally stored key server information, block <b>204</b> may direct the processor circuit <b>50</b> to signal the immediate parent key servers associated with each locally stored key (in the present example, the key server <b>36</b>), and to request that the key server transmit updated key server path information to the first device <b>26</b>. Similarly, the immediate parent key server may respond to such a request by either transmitting locally stored key server path information, or by requesting its

0070own parent key server to provide updated key server path information. Generally, it is preferable to rely upon previously stored key server path information and update only occasionally, in order to minimize communications traffic associated with the key distribution process described herein.

0071Similarly, referring to <figref idref="DRAWINGS">FIGS. 1, 2</figref>, <b>4</b>A and <b>6</b>, block <b>204</b> directs the processor circuit to store, in the device-ID list register <b>92</b>, a first device-ID path <b>512</b> representing a server path corresponding to a default or preferred device-ID, and a plurality of additional or alternative device-ID paths <b>514</b>. Each of the server paths <b>512</b> and <b>514</b> includes a name field <b>516</b> for storing a device name, a first “parent” key server field <b>518</b> for storing an identification of a first key server associated with the key, and a plurality of further key server fields <b>520</b>, for storing identifications of all intervening key servers along a secure path leading to and including the master key server <b>30</b> shown in <figref idref="DRAWINGS">FIG. 1</figref>.

0072Referring to <figref idref="DRAWINGS">FIGS. 1, 2</figref>, <b>3</b>, <b>4</b>A, <b>5</b> and <b>6</b>, in this embodiment block <b>206</b> then directs the processor circuit <b>50</b> to transmit the first list, or more particularly, the user-ID list and the device-ID list, from the first device <b>26</b> to the second device <b>28</b>. More particularly, block <b>206</b> directs the processor circuit <b>50</b> of the first device <b>26</b> to transmit, to the second device <b>28</b>, a signal <b>530</b> shown in <figref idref="DRAWINGS">FIG. 3</figref>. In this embodiment, the signal <b>530</b> includes the contents of the user-ID list register <b>90</b> shown in <figref idref="DRAWINGS">FIG. 5</figref>, and the contents of the device-ID list register <b>92</b> shown in <figref idref="DRAWINGS">FIG. 6</figref>. As a secure communications connection has not been established between the first and second devices <b>26</b> and <b>28</b>, the signal <b>530</b> is transmitted to the second device <b>28</b> in a non-secure manner, over the Internet.

0073Referring to <figref idref="DRAWINGS">FIGS. 1, 2</figref>, <b>3</b>, <b>4</b>A, <b>5</b> and <b>6</b>, as discussed above, it will be appreciated that another instance of the messaging thread <b>66</b> is being executed by the processor circuit <b>51</b> of the second device <b>28</b>. Upon receiving the signal <b>530</b>, block <b>210</b> of the messaging thread <b>66</b> directs the processor circuit <b>51</b> to block <b>212</b> shown in <figref idref="DRAWINGS">FIG. 4A</figref>, which directs the processor circuit <b>51</b> to receive at the second device, a first list of key servers potentially accessible by the first device. More particularly, block <b>210</b> directs the processor circuit <b>51</b> to receive and store the contents of the signal <b>530</b>, including the contents of the user-ID list register <b>90</b> and the device-ID list register <b>92</b>.

0074Blocks <b>214</b> and <b>216</b> then direct the processor circuit <b>51</b> of the second device to produce a second list of key servers potentially accessible by the second device, and to include in the second list, identifications of key servers associated with second device keys stored in a storage medium of the second device. Block <b>216</b> directs the processor circuit <b>51</b> to include in the second list, identifications of intermediate key servers interposed along secure communications paths between each of the key servers associated with the second device keys and a master key server. To achieve this, blocks <b>214</b> and <b>216</b> direct the processor circuit <b>51</b> to examine its own hard disk drive or other storage medium, to identify all user keys and device keys used by the second device <b>28</b>, and to locally store user-ID and device-ID key server path information similar to that shown in <figref idref="DRAWINGS">FIGS. 5 and 6</figref>, in a manner similar to that discussed above in connection with blocks <b>202</b> and <b>204</b>.

0075Block <b>218</b> then directs the processor circuit <b>51</b> of the second device <b>28</b> to compare the first and second lists, and identify, as the common key server, a key server identified in both lists. Generally, in this embodiment block <b>218</b> configures the processor circuit <b>51</b> to identify as the common key server, from among a group of key servers each of which is identified in both the first and second lists, the key server having the shortest communications paths to the first and second devices. More particularly, block <b>218</b> configures the processor circuit <b>51</b> to identify as the common key server, a key server at an intersection of a first communication path defined between a first key server having a previously established relationship with the first device and a master key server, and a second communication path defined between a second key server having a previously established relationship with the second device and the master key server. This is carried out separately for both the first and second user-ID lists for the first and second devices, and for the first and second device-ID lists for the first and second devices. To achieve this, block <b>218</b> directs the processor circuit to compare the user and device-ID lists of the first and second devices, and to identify a closest common user-ID key server and a closest common device-ID key server, that appear in the respective user-ID lists and device-ID lists of both the first and second devices. For example, in the illustrative example shown in <figref idref="DRAWINGS">FIG. 1</figref>, the second device <b>28</b> uses a user-ID key associated with the key server <b>38</b>, which follows a key server path through the common key server <b>32</b> to the master key server <b>30</b>, and also uses another user-ID key associated with the key server <b>42</b>, which follows a key server path through the key server <b>34</b> to the master key server <b>30</b>. It will be recalled that the first device <b>26</b> has a user-ID key associated with the key server <b>36</b>, which follows a key server path through the common key server <b>32</b> to the master key server <b>30</b>. Thus, in this example, the closest common user-ID key server is the common key server <b>32</b>. (There will always be at least one common key server, namely, the master key server <b>30</b>, however, in many cases a closer common key server, such as the common key server <b>32</b> in the present example, will be present.)

0076Referring to <figref idref="DRAWINGS">FIGS. 1, 2</figref>, <b>3</b>, <b>4</b>A and <b>7</b>, after identifying the closest common user-ID key server and the closest common device-ID server, block <b>220</b> directs the processor circuit <b>51</b> of the second device <b>28</b> to obtain an initial session key. More particularly, block <b>220</b> directs the processor circuit <b>51</b> to generate the initial session key at the second device, and store it in the local initial session key register (similar to the initial session key register <b>98</b> at the first device <b>26</b>). More particularly still, in this embodiment block <b>220</b> directs the processor circuit <b>51</b> to generate an 8-kilobit key for use as the initial session key.

0077In this embodiment, block <b>222</b> then directs the processor circuit <b>51</b> to transmit, from the second device <b>28</b> to the first device <b>26</b>, an identification of the common key server. Block <b>222</b> also directs the processor circuit <b>51</b> to transmit, from the second device to the first device, identifications of any intermediate key servers interposed between the first device and the common key server. In the present embodiment, block <b>222</b> also directs the processor circuit <b>51</b> to transmit the initial session key to the first device. To achieve this, block <b>222</b> directs the processor circuit <b>51</b> of the second device to generate and transmit a signal <b>540</b> to the first device <b>26</b>. As a secure communications connection has not been established between the first and second devices <b>26</b> and <b>28</b>, the signal <b>540</b> is transmitted to the first device <b>26</b> via a non-secure Internet connection established in connection with transmission of the signal <b>530</b> discussed above. In this embodiment, the signal <b>540</b> includes a first device user-ID path field <b>542</b>, a second device user-ID path field <b>544</b>, a first device device-ID path field <b>546</b>, a second device device-ID path field <b>548</b>, and an initial session key field <b>550</b>. The first device user-ID path field <b>542</b> stores path information from the first device <b>26</b> to the closest common user-ID key server. To produce the first device user-ID path field <b>542</b> contents, the processor circuit <b>51</b> of the second device locates the relevant server path record from the user-ID list received from the first device <b>26</b> (i.e., a record containing an identification of the common key server <b>32</b>), but truncates this server path information at the closest common user-ID key server, so that the last sub-field in the first device user-ID path field <b>542</b> is a common key server sub-field <b>543</b> identifying the closest common user-ID key server, which in this example is the common key server <b>32</b>. The second device user-ID path field <b>544</b> includes path information identifying the path that the second device <b>28</b> will use to communicate with the closest common user-ID key server. Thus, in the example shown in <figref idref="DRAWINGS">FIG. 1</figref>, the second device user-ID path field <b>544</b> includes a user-ID sub-field, a first parent server sub-field identifying the key server <b>38</b>, and a final server sub-field indicating the common key server <b>32</b>. The fields <b>546</b> and <b>548</b> include analogous information, corresponding to the paths that the first and second devices will respectively use to communicate with the closest common device-ID key server (which may or may not be the same as the closest common user-ID key server). Effectively, therefore, the processor circuit <b>51</b> is configured to identify intermediate key servers interposed along a communications path between one of the first and second devices and the common key server, the identifications being stored in the fields <b>542</b>, <b>544</b>, <b>546</b> and <b>548</b>. Finally, the initial session key field <b>550</b> includes the 8 kilobit initial session key generated by the processor circuit <b>51</b> of the second device <b>28</b> under the direction of block <b>220</b> above, for use in key-blending, as discussed below. In addition to transmitting the signal <b>540</b> to the first device <b>26</b>, the processor circuit of the second device also stores all of the information contained in the signal <b>540</b> locally at the second device <b>28</b>.

0078Following execution of block <b>222</b>, the processor circuit <b>51</b> of the second device <b>28</b> is directed to block <b>224</b> of the messaging thread <b>66</b> shown in <figref idref="DRAWINGS">FIG. 4B</figref>, as discussed below in connection with the processor circuit <b>50</b> of the first device <b>26</b>.

0079Referring to <figref idref="DRAWINGS">FIGS. 1, 2</figref>, <b>3</b>, <b>4</b>A and <b>7</b>, block <b>208</b> then configures the processor circuit <b>50</b> of the first device <b>26</b> to receive at the first device, from the second device, an identification of the common key server. Block <b>208</b> also configures the processor circuit <b>50</b> to obtain an initial session key, by receiving the initial session key generated by the processor circuit <b>51</b> of the second device <b>28</b>. To achieve the above, block <b>208</b> directs the processor circuit <b>50</b> to receive the signal <b>540</b>, and store its contents in the RAM <b>56</b>. More particularly, the processor circuit <b>50</b> stores the contents of the first device user-ID path field <b>542</b>, the second device user-ID path field <b>544</b>, the first device device-ID path field <b>546</b>, the second device device-ID path field <b>548</b>, and the initial session key field <b>550</b>, in a first device sub-field of the user-ID paths register <b>94</b>, a second device sub-field of the user-ID paths register <b>94</b>, a first device sub-field of the device-ID paths register <b>96</b>, a second device sub-field of the device-ID paths register <b>96</b>, and the initial session key register <b>98</b>, respectively.

0080Following execution of block <b>208</b>, the processor circuit <b>50</b> of the first device <b>26</b> is directed to block <b>224</b> of the messaging thread <b>66</b> shown in <figref idref="DRAWINGS">FIG. 4B</figref>, as discussed below.

0081Referring to <figref idref="DRAWINGS">FIGS. 1, 2</figref>, <b>3</b> and <b>4</b>B, in this embodiment, both the processor circuit <b>50</b> of the first device <b>26</b> and the processor circuit <b>51</b> of the second device <b>28</b> proceed to execute blocks <b>224</b> through <b>236</b> of the messaging thread <b>66</b>, to obtain a secure private key for use in encrypting communications between the first and second devices. Generally, blocks <b>224</b> through <b>236</b> configure each of the processor circuits <b>50</b> and <b>51</b> to obtain first and second private keys from at least one of the common key server and a second common key server potentially accessible by both the first and second devices. More particularly, in this embodiment each of the processor circuits <b>50</b> and <b>51</b> is configured to obtain, as the first and second private keys, a private user key from a common user key server and a private device key from a common device key server. In this embodiment, the common user key server and the common device key server are the closest common user-ID key server and the closest common device-ID key server respectively, as identified above at block <b>218</b> (it will be recalled that these may be the same or a different server). To achieve this, blocks <b>224</b> through <b>236</b> configure the processor circuits <b>50</b> and <b>51</b> to use the key server path information contained in the signal <b>540</b>, to cause two private session keys, namely, a user private session key and a device private session key, to be generated and securely transmitted by the closest common user-ID key server and by the closest common device-ID key server, respectively. Thus, referring to <figref idref="DRAWINGS">FIGS. 1, 2</figref>, <b>3</b>, <b>4</b>B, <b>7</b>, <b>8</b> and <b>9</b>, the first and second devices <b>26</b> and <b>28</b> contemporaneously transmit private key generation requests to their respective user-ID and device-ID key servers.

0082In this embodiment, block <b>224</b> configures the processor circuit <b>50</b> to transmit a request message to the common key server <b>32</b>, to request the common key server to transmit the private key. More particularly, block <b>224</b> directs the processor circuit <b>50</b> to transmit the request message to an intermediate key server, for relay to the common key server. More particularly still, block <b>224</b> directs the processor circuit <b>50</b> to transmit a signal <b>560</b> to the first “parent” server identified in the first device sub-field of the user-ID paths register <b>94</b> (it will be recalled that the contents of this sub-field are identical to the contents of the first device user-ID path field <b>542</b> shown in Figure <b>7</b>). Thus, in the example shown in <figref idref="DRAWINGS">FIG. 1</figref>, the first device <b>26</b> transmits the signal <b>560</b> to the key server <b>36</b>. The signal <b>560</b> specifies the respective key server paths that the first device <b>26</b> and the second device <b>28</b> wish to use to respectively communicate with the common key server <b>32</b> identified last in each such path. More particularly, the signal <b>560</b> includes a first device field <b>562</b> having contents identical to those of the first device sub-field of the user-ID paths register <b>94</b>, and a second device field <b>564</b> having contents identical to those of the second device sub-field of the user-ID paths register <b>94</b>. The signal <b>560</b> is transmitted in a secure manner to the key server <b>36</b>, via a secure connection established using a key corresponding to the key server path information contained in the first device sub-field of the user-ID paths register <b>94</b>.

0083Similarly, to request a device private session key, block <b>224</b> also directs the processor circuit <b>50</b> of the first device <b>26</b> to transmit an analogous signal shown generally at <b>566</b> in <figref idref="DRAWINGS">FIG. 9</figref>, to the first “parent” server identified in the first device sub-field of the device-ID paths register <b>96</b> (it will be recalled that the contents of this sub-field are identical to the contents of the first device device-ID path field <b>546</b> shown in <figref idref="DRAWINGS">FIG. 7</figref>). In general, this first “parent” server for the device-ID path will not be the same server as for the user-ID path, however, it is possible for these two servers to coincide. As the manner in which the device private session key is obtained is identical to the manner in which the user private session key is obtained, for ease of illustration, only the generation and transmission of the user private session key is described and illustrated herein.

0084Referring to <figref idref="DRAWINGS">FIGS. 1, 2</figref>, <b>3</b>, <b>4</b>B, <b>7</b>, <b>8</b> and <b>9</b>, block <b>224</b> of the instance of the message thread <b>66</b> concurrently executing on the processor circuit <b>51</b> of the second device <b>28</b> directs the processor circuit <b>51</b> to request user and device private session keys in a similar manner (the discussion of the device private session key being omitted for ease of illustration). To request a user private session key, the processor circuit <b>51</b> of the second device is directed to transmit a signal <b>570</b> shown in <figref idref="DRAWINGS">FIG. 3</figref>, to the first “parent” server identified in the second device user-ID path field <b>544</b> shown in <figref idref="DRAWINGS">FIG. 7</figref>. In the illustrative example shown in <figref idref="DRAWINGS">FIG. 1</figref>, this first “parent” server is the key server <b>38</b>. The contents of the signal <b>570</b> are identical to those of the signal <b>560</b> shown in <figref idref="DRAWINGS">FIG. 8</figref>. The signal <b>570</b> is transmitted in a secure manner to the key server <b>38</b>, via a secure connection established using the key corresponding to the key server path information contained in the second device user-ID path field <b>544</b>.

0085The first “parent” servers, in this example the key servers <b>36</b> and <b>38</b>, proceed to forward the requests for a user private session key to the closest common user-ID key server, either directly, or via one or more intermediate key servers (if any) identified along the paths specified in the signals <b>560</b> and <b>570</b>. To achieve this, the key server <b>36</b> includes the processor circuit <b>136</b>, which is configured or programmed by a secure communications routine including a key server thread <b>74</b> similar to that shown in <figref idref="DRAWINGS">FIG. 2</figref> in connection with the first device <b>26</b>. The key server thread <b>74</b> configures the processor circuit <b>136</b> of the key server <b>36</b> to receive the request message (i.e., the signal <b>560</b>) from the first device <b>26</b> requesting a private key, and to relay the request message to a common key server potentially accessible by both the first and second devices (in this case, the common key server <b>32</b>). To achieve this, the key server thread <b>74</b> directs the processor circuit <b>136</b> to examine the contents of the first device field <b>562</b> of the signal <b>560</b>, to determine whether the request message is intended for itself or for its own “parent” key server or a successive parent thereof. If the identification of the key server <b>36</b> is the last server identification in the first device field <b>562</b>, then the signal <b>560</b> is intended for the key server <b>36</b>; otherwise, if the identification of the key server <b>36</b> appears earlier in the sub-field (as in the present example), the processor circuit <b>136</b> is configured to relay the signal to the next successive parent key server identified in the first device field <b>562</b> of the signal <b>0</b>.<b>560</b>.

0086Likewise, in this embodiment the key server <b>38</b> includes the processor circuit <b>138</b>, which is similarly configured to relay the request message from the second device <b>28</b> to the common key server <b>32</b>, in response to the second device field contents of the signal <b>570</b>.

0087In this embodiment, the processor circuits <b>136</b> and <b>138</b> are configured or programmed to respond to such request messages as described herein. When the key server <b>36</b> receives the signal <b>560</b> from the first device <b>26</b>, upon recognizing that the signal <b>560</b> is intended for its parent server or a successive parent thereof as described above, the processor circuit <b>136</b> is directed to place the connection with the first device <b>26</b> on “pause”, and to transmit a signal <b>580</b> to the next successive key server identified in the first device field <b>562</b> of the signal <b>560</b>. In the illustrative example shown in <figref idref="DRAWINGS">FIG. 1</figref>, the next successive key server is the closest common user-ID key server, which in this case is the common key server <b>32</b>. The signal <b>580</b> is transmitted from the key server <b>36</b> to the common key server <b>32</b> in a secure manner, using a secure Internet connection between the key servers (more generally, in this specification, unless otherwise indicated, all communications among a device or key server and its “parent” key server are presumed to be via secure communications channels, as discussed above). The signal <b>580</b> includes the information contained in the signal <b>560</b>.

0088Similarly, when the key server <b>38</b> receives the signal <b>570</b> from the second device <b>28</b>, the processor circuit <b>138</b> is configured to place the secure connection with the second device on “pause”, and to effectively relay the signal <b>570</b>, by transmitting a signal <b>590</b> to the next successive key server identified in the second device field of the signal <b>570</b>, which in this example is the common key server <b>32</b>, over a secure communications connection therebetween.

0089Referring to <figref idref="DRAWINGS">FIGS. 1, 3</figref> and <b>10</b>, the common key server <b>32</b> includes the processor circuit <b>132</b>, which is configured or programmed by a secure communications routine including a key server thread <b>74</b> similar to that shown in <figref idref="DRAWINGS">FIG. 2</figref> in connection with the first device <b>26</b>. The key server thread <b>74</b> configures the processor circuit <b>132</b> to receive such request messages from first and second intermediate servers interposed between the common key server and the first and second devices respectively, requesting a private key. The processor circuit <b>132</b> is configured to generate and transmit the private key to the first and second intermediate servers in response to the request messages, for relay to the first and second devices. Thus, in the present embodiment, when the common key server <b>32</b> receives the signals <b>580</b> and <b>590</b>, the processor circuit <b>132</b> of the common key server is configured to first determine whether the signals are intended for itself, or whether the signals are intended to be relayed to a next successive parent key server. If the identification of the common key server <b>32</b> appears last in the first device field of the signal <b>580</b> and in the second device field of the signal <b>590</b>, the processor circuit is configured to recognize that the signals are intended for itself, and is configured to respond accordingly by generating a private key, which in this embodiment has a length of 8 kilobits. The processor circuit <b>132</b> is also directed to produce a hash value corresponding to the generated private key. In this embodiment the hash value is produced using the SHA1 hashing algorithm, although alternatively, other hashing algorithms may be substituted. The processor circuit <b>132</b> of the common key server <b>32</b> then transmits a signal <b>600</b> to the key server <b>36</b>, and transmits an identical signal <b>610</b> to the key server <b>38</b>, via the respective secure communications connections established above in connection with the signals <b>580</b> and <b>590</b>. As shown in <figref idref="DRAWINGS">FIG. 10</figref>, the signal <b>600</b> includes a private session key field <b>602</b> and a hash value field <b>604</b>, storing the generated user private session key and the hash value, respectively.

0090The processor circuit <b>136</b> of the intermediate key server <b>36</b> then receives the private key from the common key server and relays the private key for receipt by the one of the first and second devices. More particularly, when the key server <b>36</b> receives the signal <b>600</b>, the processor circuit <b>136</b> is configured to resume the secure connection between itself and the processor circuit <b>50</b> of the first device <b>26</b> that was established in connection with the signal <b>560</b>. The processor circuit <b>136</b> of the key server <b>36</b> securely transmits, to the first device <b>26</b>, a signal <b>620</b> having contents identical to those of the private session key field <b>602</b> and the hash value field <b>604</b> of the signal <b>600</b>.

0091In this embodiment, block <b>226</b> then configures the processor circuit <b>50</b> of the first device <b>26</b> to obtain the private key from one of the intermediate key servers that has received the private key from the common key server (in this case, from the intermediate key server <b>36</b>). More particularly, in this embodiment block <b>226</b> directs the processor circuit <b>50</b> to receive the signal <b>620</b>, and to store the received user private session key in a user private session key field of the private keys register <b>100</b> in the RAM <b>56</b>. As the signal <b>600</b> transmitting the user private session key from the common key server <b>32</b> to the intermediate key server <b>36</b> was secure, as was the signal <b>620</b> relaying the key from the intermediate key server <b>36</b> to the first device, it will be appreciated that the processor circuit <b>50</b> is effectively configured to receive the private key from the common key server via a secure communications channel.

0092Block <b>228</b> then configures the processor circuit <b>50</b> to validate the private key relayed to it by the intermediate key server <b>36</b>. More particularly, block <b>228</b> directs the processor circuit <b>50</b> to validate the private key by receiving a first hash value produced by the common key server in response to the private key, generating a second hash value in response to the received private key, and comparing the first and second hash values. More particularly still, block <b>228</b> directs the processor circuit <b>50</b> to receive and store the hash value received in the signal <b>620</b>, which was generated by the common key server <b>32</b>. Block <b>228</b> then directs the processor circuit <b>50</b> to generate a hash value in response to the contents of the user private session key field of the private keys register <b>100</b>, using the same hashing algorithm as that used by the common key server <b>32</b> (in this embodiment, the SHA1 hashing algorithm). Block <b>228</b> further directs the processor circuit <b>50</b> to compare the generated hash value to the hash value received in the signal <b>620</b>. Any difference between the generated and received hash values indicates that the private key has been corrupted in transit and should not be used.

0093Similarly, when the key server <b>38</b> receives the signal <b>610</b>, it resumes the secure connection established between itself and the second device <b>28</b> that was established in connection with the signal <b>570</b>. The key server <b>38</b> then transmits, to the second device, a signal <b>630</b> including the user private session key and the hash value. Blocks <b>226</b> and <b>228</b> of the instance of the messaging thread <b>66</b> that is concurrently executing on the second device <b>28</b> direct the processor circuit <b>51</b> to store the user private session key locally thereat, and to perform a hash value verification as discussed above in connection with the first device.

0094Thus, when the first device <b>26</b> and the second device <b>28</b> receive the signals <b>620</b> and <b>630</b> respectively, they now have a user private session key that may be used for secure communications between the first and second devices. Advantageously, in the present embodiment, the potentially exploitable security weaknesses associated with asymmetric encryption are avoided by utilizing symmetrical encryption for all secure communications methods during the establishment of a private symmetrical key.

0095Although the user private session key was transmitted from the common key server <b>32</b> to the first and second devices <b>26</b> and <b>28</b> using symmetrical encryption methods, in the present embodiment, additional security enhancements are provided to even further Minimize security risks.

0096Accordingly, to provide such enhancements in this embodiment, a plurality of keys are effectively blended together. In this regard, as noted the first and second devices <b>26</b> and <b>28</b> also request and obtain a device private session key from the closest common device-ID key server, in a manner analogous to that described above in connection with signals <b>560</b> through <b>630</b> in relation to the user private session key. The first device <b>26</b> stores the device private session key in a device private session key field of the private keys register <b>100</b>, and the second device <b>28</b> also stores the obtained device private session key. In addition, it will be recalled that an initial session key was generated and is stored at each of the first and second devices, as discussed above in connection with the signal <b>540</b> and blocks <b>220</b> and <b>208</b>.

0097Thus, in this embodiment, blocks <b>230</b> to <b>234</b> direct each of the processor circuits <b>50</b> and <b>51</b> to blend the first and second private keys (i.e., the user private session key and the device private session key) and the initial session key to produce a modified key. In this regard, block <b>230</b> directs the processor circuit <b>50</b> to encrypt at least one of the first and second private keys and the initial session key using at least one other of the first and second private keys and the initial session key. More particularly, block <b>230</b> directs the processor circuit <b>50</b> to encrypt the first private key using the second private key to produce a once-encrypted key. More particularly still, block <b>230</b> directs the processor circuit <b>50</b> to use the device private session key (stored in the device private session key field of the private keys register <b>100</b>) to encrypt the user private session key (stored in the user private session key field of the private keys register <b>100</b>), to produce a once-encrypted key.

0098In this embodiment, block <b>232</b> then directs the processor circuit <b>50</b> to encrypt the once-encrypted key using the initial session key (stored in the initial session key register <b>98</b>) to produce a twice-encrypted key. The twice-encrypted key is stored in the blended key register <b>102</b>.

0099Block <b>234</b> then directs the processor circuit <b>50</b> to generate a hash value in response to the twice-encrypted key, and append the hash value to the twice-encrypted key. More particularly, the processor circuit is directed to calculate a hash value of the twice-encrypted key, using the SHA1 hashing algorithm. The processor circuit is then directed to append the hash value to the end of the twice-encrypted key.

0100Block <b>234</b> further directs the processor circuit <b>50</b> to delete a portion of the twice-encrypted key other than the hash value appended thereto, the deleted portion having a length equal to the hash value appended thereto. More particularly, the processor circuit is directed to delete, from the beginning of the twice-encrypted key, a length equal to the length of the hash value it has just appended to the end of the key, thereby restoring the key to its original length.

0101Block <b>234</b> then directs the processor circuit <b>50</b> to repeat the steps of generating and appending a hash value to the twice-encrypted key and deleting a portion of the twice-encrypted key until the twice-encrypted key has been entirely replaced with appended hash values. More particularly, the processor circuit is directed to take the resulting modified key resulting from the above steps of appending and deleting, and to repeat the above hashing, appending and deleting steps, a plurality of times. In this embodiment, these steps are performed 52 times, at the end of which the entire original twice-encrypted key will have been completely deleted and replaced with appended hash values. The result, following such repetition of this hashing procedure, is a final, private session key, that may be used in establishing a secure communications connection between the first and second devices <b>26</b> and <b>28</b>. Block <b>236</b> directs the processor circuit <b>50</b> to store this key in the final private session key register <b>104</b>.

0102Similarly, blocks <b>230</b> through <b>236</b> of the concurrently executing messaging thread <b>66</b> on the second device <b>28</b> direct the processor circuit <b>51</b> to perform identical blending and hashing procedures, to generate and store a final private session key identical to that generated and stored in the final private session key register <b>104</b> of the first device <b>26</b>.

0103Thus, the final private session key so generated is a truly private key, with no corresponding root keys stored in a software program or on the device or on a publicly accessible key server. As the final private session key has not been directly transmitted over the Internet at all, and no devices other than the first and second devices have all the data necessary to create the final private session key, security is considerably enhanced as compared to conventional secure communications systems. In addition, in the present example, the final private session key was obtained by first and second devices that did not share any immediate parent key server in common (i.e., there was no single server with which both the first and second devices had previously exchanged keys to enable secure communication therebetween). The common key server <b>32</b> was identified automatically by the processor circuits <b>50</b> and <b>51</b> under the directionof the messaging thread <b>66</b>, without requiring the users of the first and second devices to have any advance knowledge of each other's key servers (or indeed, of their own key servers).

0104Once such a final private session key has been obtained by both the first and second devices <b>26</b> and <b>28</b> in the above manner, secure communications therebetween may be carried out. For example, the first device <b>26</b> may transmit a signal <b>650</b> to the second device <b>28</b>, and the second device may transmit a signal <b>640</b> to the first device <b>26</b>, both such signals being encrypted in response to the final private session key. If either such signal is received before the receiving device has finished producing the final private session key, the information encoded in the signal may be simply stored in a buffer until the required key has been produced.

0105In the present embodiment, such encrypted communications are handled by the various other threads of the secure communications routine <b>62</b>, as discussed in greater detail below. Alternatively, however, numerous other ways of implementing secure communications between the first and second devices using the final private session key would be apparent to one of ordinary skill in the art upon reviewing this specification. In general, any suitable encryption method may be employed.

0106However, a particularly advantageous encryption method, employing a modified ARC4 streaming cipher encryption method with session control, is briefly described for illustrative purposes.

0000Encryption/Decryption Thread

0107Referring back to <figref idref="DRAWINGS">FIG. 2</figref>, in the present embodiment, the encryption/decryption thread <b>68</b> co-operates with the various other threads (described briefly below) of the secure communications routine <b>62</b> to configure the processor circuits <b>50</b> and <b>51</b> to encrypt communications between the first and second devices in response to the private key. More particularly, each processor circuit is configured to encrypt communications using a blended key produced in response to the private key. More particularly still, such encryption occurs using the final private session key produced in response to the first and second private keys and the initial session key (stored in the final private session key register <b>104</b>). For ease of illustration, only the processor circuit <b>50</b> of the first device <b>26</b> is described, it being understood that the processor circuit <b>51</b> of the second device <b>28</b> is similarly configured.

0108In this embodiment, the encryption/decryption thread <b>68</b> configures the processor circuit <b>50</b> to initiate a cipher communications session using the blended key described above. More particularly, the processor circuit is configured to use the final private session key stored in the final private session key register <b>104</b>, to initiate and execute a modified ARC4 streaming cipher communications session, the communications stream including session control information, key server information, and user data.

0109In this embodiment, the encryption/decryption thread <b>68</b> directs the processor circuit <b>50</b> to determine whether outgoing data has been placed in either the send buffer <b>110</b> or the key send buffer <b>112</b> for encryption and transmission to the second device. If so, the processor circuit is directed to encrypt up to one 64 kB block of data in accordance with the modified ARC4 algorithm described below, and to append a header to the encrypted block, the header including the length of the block, a data verification value produced in response to the length, and a flag indicative of whether the block represents user data from the send buffer <b>110</b> or key data from the key send buffer <b>112</b>. Similarly, the encryption/decryption thread <b>68</b> directs the processor circuit to decrypt received data that has been placed in the pipe receive global buffer <b>118</b> under the direction of the pipe control/TCP send thread <b>70</b>, by decrypting such data according to the modified ARC4 algorithm described below, and storing the decrypted data in either the receive buffer <b>122</b> or the key receive buffer <b>120</b>, depending on whether the header flag indicates user data or key data, respectively.

0110In the present embodiment, the encryption/decryption thread <b>68</b> includes a number of modifications to the conventional ARC4 method. It will be appreciated that the conventional ARC4 method involves use of an array produced in response to the relevant key, referred to as an S-array, to encrypt communications. The conventional ARC4 method is designed to use 2 kilobit keys, whereas the present embodiment of the invention employs 8 kilobit or 1 kiloByte keys. Accordingly, in this embodiment the ARC4 algorithm is modified to accommodate the larger key size of the final private session key, and the corresponding larger size of the S-array. For example, in the initialization and definition of the S-array, and the temporary K-array used to assist in this initialization and definition process, the modulus or remainder operator is changed from MOD <b>256</b> to MOD <b>1024</b>. Similarly, many of the For-Next loop indices are ranged from 0 to 1023 rather than 0 to 255. Further necessary modifications in this regard will be readily apparent to one of ordinary skill in the art upon review of the instructions disclosed herein.

0111In addition, in the present embodiment, during the initial definition of the S-array, the conventional ARC4 algorithm includes a swapping or shuffling loop, whereby each entry in the S-array is swapped with one other entry in the S-array. The conventional ARC4 algorithm executes this swapping loop once. However, in the present embodiment, in which a larger S-array is employed, the processor circuit <b>50</b> is configured to repeat the shuffling loop of the ARC4 streaming cipher communications session, a prime number of times greater than two. For example, in this embodiment the shuffling or swapping loop is repeated 13 times, to reduce the statistical likelihood that the repeated swapping may tend to restore the array to a configuration closer to its original configuration.

0112In this embodiment, both the first and second devices are configured or programmed to generate the S-array in the same way. Accordingly, as they will both begin with an identical final private session key, they will both arrive at the same initial S-array, with which to commence encrypted communications.

0113Once the S-array has been initialized and generated in this manner, it may then be used by the “inner loop” of the ARC4 algorithm to encrypt communications between the first and second devices. It will be appreciated that the ARC4 streaming cipher effectively modifies the encryption key each time a new character is encrypted. In this embodiment, the inner loop of the ARC4 algorithm is re-written in assembler language, for faster processing. In this embodiment, the modified inner loop of the ARC4 algorithm includes four main steps for encrypting each successive character. First, a looping counter i ranging from 0 to 1023 is incremented (resetting to 0 after 1023). Second, a random location of the S-array is selected, by setting a value j_current=[j_previous+S(i)]MOD<b>1024</b>. Third, the contents of two locations of the S-array, namely, S(i) and S(j), are swapped. Fourth, a mixing value is selected, by taking a value [S(i)+S(j)]MOD<b>1024</b>, using this value as an array location index to look up a value stored in the S-array, or in other words, S([S(i)+(j)]MOD<b>1024</b>), taking the modulus or remainder operator <b>256</b> of this value, or in other words, S([S(i)+S(j)]MOD<b>1024</b>)MOD<b>256</b>, and performing an exclusive OR operation on the current character and this latter value, to yield (encrypted character)=(current character)XOR[S([S(i)+S(j)]MOD<b>1024</b>)MOD<b>256</b>]. It will be appreciated that this latter step is a further modification of the conventional ARC4 algorithm, which performs the XOR operation using [S([S(i)+S(j)]MOD<b>256</b>)] rather than [S([S(i)+S(j)]MOD<b>1024</b>)MOD<b>256</b>].

0114Additionally, in this embodiment, the values used by the inner loop of the modified ARC4 algorithm, including the entire S-array and the counter indices i and j, are saved following encryption of each block of data, so that when the next block of data is to be encrypted in the same session, the previously saved S-array and counter values are used. Therefore, in this embodiment, the S-array does not have to be re-initialized following encryption of each block of data. Rather, the encryption proceeds continuously throughout the entire communications session between the first and second devices. Effectively, the entire communications session, which may involve transmission of a large number of data blocks (which in this embodiment are 64 kB blocks), is treated as if it were a single block for the purpose of the changing encryption key value, as the encryption key is never re-initialized during the session.

0115As noted, the data stream encrypted using the modified ARC4 algorithm as described above includes session control information, key server information, and user data. In this embodiment, the session control value is a calculated value that changes according to pre-defined rules over successive time periods. For example, the session control value may be changed every 5 seconds, and may be changed according to a seeded pseudo-random number generation scheme, or any suitable alternative method. When the session is first established, one of the first and second devices transmits an initial session control value to the other device. Each of the first and second devices calculates a next expected session control value, that it expects to receive from the other device during the next successive time period. Periodically (e.g., once per time period), each device checks the session control value presently received from the other device, and if the received session control value is not equal to the expected session control value, the device terminates the communications session with the other device.

0116In this embodiment, a data verification value is produced for each data block and is appended to the data block before the data block is encrypted. In this embodiment, each data block has a size of 64 kB. In this regard, although conventional methods such as the SHA1 hashing algorithm could conceivably be used to produce hash values to act as data verification values for the various data blocks, the SHA1 algorithm tends to entail an undesirably large amount of overhead for use on every data block to be transmitted and received. In addition, the level of security required for the data verification value is lessened in the present embodiment, due to the fact that the data verification value is encrypted along with the data block. Accordingly, in this embodiment an alternative data verification value is produced, as follows. To produce the data verification value for a data string having a length L, the data verification value, which has 4 bytes, is initially set to zero. Then, for each character in the data string, a specific successive byte of the data verification value is modified: the first byte is modified for the first, fifth, ninth, etc. characters of the data string, the second byte is modified for the second, sixth, tenth, etc. characters. For illustrative notational purposes, if the four bytes are labelled byte#0, byte#1, byte#2 and byte#3, and the character location of each character in the data string is denoted by x (0≦x≦(L−1)), then for the x^thcharacter, byte#(xMOD<b>4</b>) is modified. The identified byte of the data verification value is first subjected to an XOR operation with the ((L−1)−x)^thcharacter of the data string (for example, for the first character at location x=0, byte#0 of the data verification value is XOR'd with the last or (L−1)^thcharacter of the data string.) The resulting value is then subjected to an XOR operation with xMOD<b>256</b>. This is repeated for each of the L values of the data string, to arrive at the final data verification value for the data string.

0000Other Threads

0117It will be recalled that in the present embodiment, the user applications <b>64</b> do not interface directly with the TCP/IP functionality of the operating system <b>60</b>. Rather, the user applications <b>64</b> interface with the secure communications routine <b>62</b>, which is provided in the form of a dynamic link library (.dll) file, and which establishes and handles all TCP/IP communications.

0118Generally, the TCP receive thread <b>72</b> directs the processor circuit <b>50</b> to continuously poll an operating system TCP receive buffer and append blocks of any received data to the pipeline control buffer <b>116</b>, checking for TCP errors and appending errors.

0119In this embodiment, the pipe contro/TCP send thread <b>70</b> generally directs the processor circuit <b>50</b> to both transmit and assist in receiving data. For example, the pipe control/TCP send thread directs the processor circuit to check whether any outgoing data has been placed in the global pipe send buffer <b>114</b>. If so, the processor circuit is directed to remove up to one 64 kB block of such data, to append a header to the block (in this embodiment the header includes a length of the block, a data verification value produced in response to the length, and a data flag indicating whether the block represents session control information or user data), to store the block in a local send buffer (not shown), and to invoke an operating system TCP send function to transmit the block to the second device. The pipe control/TCP send thread <b>70</b> also directs the processor circuit <b>50</b> to periodically calculate a new session control value (as discussed above in connection with the encryption/decryption thread <b>68</b>), for each new successive time period of the session, and to transmit the session control value to the second device in a similar manner. The pipe control/TCP send thread <b>70</b> also assists in receiving data, by directing the processor circuit to determine whether data has been placed in the pipeline control buffer <b>116</b> under the direction of the TCP receive thread <b>72</b>, and if so, to parse the received data into data blocks. If the received data is session control information, the processor circuit is directed to compare the received session control value to the expected value, and to terminate the session with the second device if they are not equal, as discussed above. If the received data is user data (as indicated by a flag in the header), the processor circuit is directed to store the received data blocks in the pipe receive global buffer <b>118</b>. The pipe control/TCP send thread <b>70</b> also directs the processor circuit to terminate the session with the second device if no session control value has been received in a time period exceeding a threshold timeout value.

0120In the present embodiment, the data object monitor thread <b>76</b> configures the processor circuit <b>50</b> to provide cross-object statistical information, including global error notification, within the secure communications layer, the applications layer, and optionally to the end user if the communications layer is running in debug mode. Also in this embodiment, the data object monitor thread configures the processor circuit to clear deadlocks that could potentially occur in the global memory registers, clean up locks on global memory registers that may have timed out, and perform memory management operations (e.g. garbage collection) when an object is destroyed.

0121In this embodiment, the key server thread <b>74</b> is included in the secure communications routine <b>62</b>, to allow the processor circuit <b>50</b> to function as a key server, including performing the functions of the intermediate key server <b>36</b> and the common key server <b>32</b> as described earlier herein, for example. In this embodiment, the messaging thread <b>66</b> cooperates with the key server thread <b>74</b> to configure the processor circuit <b>50</b> to process key management tasks for both client operations and server operations. In turn, the key server thread <b>74</b> cooperates with the messaging thread <b>66</b> and its associated threads to configure the processor circuit to perform the actual sending and receiving of the data (it will be recalled that in the present embodiment, the pipe control/TCP thread identifies transmitted data as user data (application data,) control data (pipe control data), or the key data (key server thread data). The cooperation of the threads to achieve such functionality tends to significantly reduce the size of the secure communications routine <b>62</b> and its complexity as duplication of programming logic is avoided.

0122In the present embodiment, the threadsafe function <b>80</b> includes sub-functions that allow the processor circuit <b>50</b>, under the direction of a particular thread, to lock or unlock the contents of a data field, to copy the contents of a data field, to remove or cut the contents of a data field, to put data into a field replacing its former contents, to remove only a single block of data from a field on a first-in-first-out basis, to append data to a buffer, to initialize a buffer size, and other similar data management functions. The threadsafe function <b>80</b> cooperates with the data object monitor thread <b>76</b> discussed above to achieve such functionality.

0123Alternatively, however, other suitable delineations of functionality among the various threads may be substituted. More generally, any other suitable way of causing a processor circuit or equivalent device to perform the functions herein may be substituted without departing from the scope of the present invention.

0124More generally still, while specific embodiments of the invention have been described and illustrated, such embodiments should be considered illustrative of the invention only and not as limiting the invention as construed in accordance with the accompanying claims.