Abstract:
Techniques concerning the communication of messages, and verification of connections, between communication units in a network of communication units are disclosed. An intermediate communication unit either routes messages to other communication units or further processes such messages based on whether it is able to successful interpret such messages based on at least one shared secret maintained by the intermediate communication unit. In this manner, initiating and target communication units can verify connections therebetween.

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
       [0001]    The instant application is related to co-pending application entitled “AUTHENTICATION OF COMMUNICATION UNITS” having attorney docket number 48702.00.0003, filed on even date herewith. 
       FIELD 
       [0002]    The instant disclosure relates generally to communications networks and, in particular, to message routing between communication units and the verification of connections therebetween. 
       BACKGROUND 
       [0003]    Securing the privacy and integrity of communications has become an issue of increasing importance in recent years, particularly over networks of entities communicating with each other. An example of such a communication network is illustrated in  FIG. 1  in which a plurality of endpoints or communication units, labeled A-F, have a corresponding plurality of connections  102  therebetween. Generally, a communication unit may be considered any processing-capable device capable of supporting the communication protocols necessary for communicating with another communication unit. For example, in the case of the Internet, centrally-managed, cryptographic techniques such as public key infrastructure (PKI) in cooperation with the Secure Sockets Layer (SSL) and Transportation Layer Security (TLS) protocols have been used for many years for both authentication and verification purposes. As used herein, authentication is the determination of identity, i.e., that a given communication unit is, in fact, the communication unit known within a network of communication units. Verification, on the other hand, is a determination that a so-called man-in-the-middle (MitM) attack is not occurring between two communication units, an example of which illustrated in  FIG. 2 . As shown in  FIG. 2 , a MitM attacker  202  is able to intercept messages sent between two communication units A, B over respective connections  204   a ,  204   b  that, from the perspective of the affected communication units A, B, appear to be a single connection terminated by each other when, in fact, they are terminated by the MitM attacker  202 . Particularly, is this example, the MitM attacker  202  effectively implements two separate communication units X 1 , X 2  each of which is capable of cryptographically communicating with corresponding ones of the affected communication units A, B. Thus, the MitM attacker  202  can decrypt any encrypted messages sent by the affected communication units A, B in order to monitor and, if desired, re-encrypt such messages or substitute and encrypt its own messages. In this manner, the affected communication units A, B believe they are securely communicating with each other when, in fact, all of their communications are susceptible to monitoring and tampering. 
         [0004]    While existing authentication and verification techniques have proved serviceable, the administrative burden to implement such technologies can be significant and various cryptographic weaknesses of such systems have been found. More recently, techniques have been developed that eliminate the need for centralized cryptographic implementation. For example, the Pretty Good Privacy (PGP) program, building on the use of public and private encryption keys, permits endpoints to establish their own cryptographic communications without the need for centralized management. Though not required, authentication of individual users is advisable to ensure that a public key used to send messages to that user is actually associated with him/her. While manually-implemented techniques exist for ensuring such authentication, many users are simply not interested in performing them. 
         [0005]    Another example of a distributed cryptographic technique is the Zimmerman Real-Time Transport Protocol (ZRTP) more fully described in U.S. Pat. No. 7,730,309, the teachings of which are incorporated herein by this reference. ZRTP provides end-to-end verification of voice over IP (VoIP) communications through establishment of shared secrets that serve as the basis for ephemeral session keys and inter-session key continuity. Based on these features, in which encryption keys for a given session expire after that session and are further used to establish the encryption keys used in a subsequent session, all subsequent sessions between two communication units can proceed with the assurance that a MitM attack is not occurring unless such a MitM attack was established during the initial session and ZRTP setup between the communication units. To further prevent MitM attacks, ZRTP also incorporates use of so-called short authentication strings (SASs) that are derived from session keys and permit oral comparison to ensure continuing verification context. While effective, ZRTP is arguably vulnerable if users are not diligent in ensuring ongoing verification context, i.e., comparing SASs each session. Additionally, use of SASs every time a new connection is established between endpoints could become burdensome, particularly when one considers the frequency with which user tend change devices. Further still, the use of effective techniques like SASs is not an option for typically unattended endpoints, i.e., the Internet of Things, where a use is unable perform an oral confirmation of a SAS. 
         [0006]    Thus, it would be advantageous to provide techniques that address the shortcomings of existing technologies. 
       SUMMARY 
       [0007]    The instant disclosure describes various techniques concerning the communication of messages, and verification of connections, between communication units in a network of communication units. In an embodiment, an intermediate communication unit receives a first message from a first communication unit that has a first connection with the intermediate communication unit that the intermediate communication unit previously designated as being verified. The intermediate communication unit interprets the first message based on at least one shared secret maintained by the intermediate communication unit, and further processing of the first message is performed according to whether the intermediate communication unit is able to successfully interpret the first message. In an embodiment, the first message may comprise a first encrypted message and interpretation thereof comprises decryption of the first encrypted message based on the at least one shared secret. In a further embodiment, the first message may comprise a message authentication code (MAC) based on the first message and the at least one shared secret. If the intermediate communication unit is unable to successfully interpret the first message according to the at least one shared secret, the intermediate communication unit sends the first message to at least one second communication unit, each of which has a connection with the intermediate communication unit previously designated by the intermediate communication unit as being verified. If the intermediate communication unit successfully interprets the first message, it determines whether the successful shared secret corresponds to a connection (i.e., another communication unit) previously designated by the intermediate communication unit as being verified. If so, the intermediate communication unit was the intended target of the first message and processes the first message accordingly. On the other hand, if the successful shared secret does not correspond to a previously verified connection, then the intermediate communication unit, again being the intended target of the first message, first designates that connection as being verified and then processes the first message accordingly. As a continuation of the verification process, i.e., to validate itself to that other communication unit with which it shares the successful shared secret, the intermediate communication unit can generate a second message based on the successful shared secret and send the second message to at least one selected intermediate communication unit, the connections corresponding to each of the at least one selected intermediate communication units having been previously verified by the intermediate communication unit. Once again the second message may comprise a second encrypted message a MAC. 
         [0008]    In another embodiment, an initiating communication unit establishes a first connection with a target communication unit, including the establishment of a first shared secret known to both the initiating and target communication units. The initiating communication unit thereafter creates a first message based on the first shared secret and sends the first message to at least one intermediate communication unit having a connection with the initiating communication unit previously designated by the initiating communication unit as being verified. Thereafter, the initiating communication unit receives a second message from the at least one intermediate communication unit and interprets the second message based on the first shared secret. When the initiating communication unit is able to successfully interpret the second message based on the first shared secret, the initiating communication unit designates the first connection with the target communication unit as being verified. As before, the first and second messages may be encrypted messages and comprise a MAC. Where the second message comprises a received MAC, the initiating communication unit may determine a computed MAC based on the second message and compare the received and computed MACs. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0009]    The features described in this disclosure are set forth with particularity in the appended claims. These features and attendant advantages will become apparent from consideration of the following detailed description, taken in conjunction with the accompanying drawings. One or more embodiments are now described, by way of example only, with reference to the accompanying drawings wherein like reference numerals represent like elements and in which: 
           [0010]      FIG. 1  is a schematic illustration of a network of communication units in accordance with prior art techniques; 
           [0011]      FIG. 2  is a schematic illustration of a man-in-the-middle attack in accordance with prior art techniques; and 
           [0012]      FIG. 3  is a block diagram illustrating an example of a communication unit in accordance with the instant disclosure; 
           [0013]      FIG. 4  is a flow chart illustrating verification operation of an initiating communication unit in accordance with the instant disclosure; 
           [0014]      FIG. 5  is a flow chart illustrating routing and verification operation of an intermediate communication unit in accordance with the instant disclosure; 
           [0015]      FIGS. 6-8  illustrate an example of routing and verification operation in accordance with the instant disclosure; 
           [0016]      FIG. 9  is a flow chart illustrating authentication operation of an initiating communication unit in accordance with the instant disclosure; 
           [0017]      FIG. 10  is a flow chart illustrating in greater detail identification of an intermediate communication unit by an initiating communication unit during authentication operation in accordance with the instant disclosure; 
           [0018]      FIG. 11  is a flow chart illustrating authentication operation of an intermediate communication unit in accordance with the instant disclosure; 
           [0019]      FIG. 12  is a flow chart illustrating authentication operation of a target communication unit in accordance with the instant disclosure; and 
           [0020]      FIGS. 13-19  illustrate examples of authentication operation in accordance with the instant disclosure. 
       
    
    
     DETAILED DESCRIPTION OF THE PRESENT EMBODIMENTS 
       [0021]    Referring now to  FIG. 3 , an example configuration for communication unit  300  is illustrated in block diagram form. The communication unit  300  comprises a number of components such as a main processor  302  that controls the overall operation of the communication unit  300 . Communication functions, including data and voice communications, are performed through a communication subsystem  304 . The communication subsystem  304  implements various communication protocols that all it to receive messages from and send messages to a wireless network  350 . For example, the communication subsystem  304  may be configured in accordance with the well-known GSM (Global System for Mobile Communications) and GPRS (General Packet Radio Service) standards. Other communication configurations that are equally applicable include the so-called 3G and 4G telecommunication networks known in the art. As will be appreciated by those of skill in the art, new standards are still being defined that are likely to have functional similarities to the network behavior described herein, and it is understood that the embodiments described herein are intended to use any other suitable standards that are developed in the future. The wireless link connecting the communication subsystem  304  with the wireless network  350  represents one or more different Radio Frequency (RF) channels, operating according to defined protocols specified for GSM/GPRS communications. 
         [0022]    The main processor  302  also interacts with additional subsystems such as a Random Access Memory (RAM)  306 , a flash memory  308 , a display  310 , an auxiliary input/output (I/O) subsystem  312 , a data port  314 , a keyboard  316 , a speaker  320 , a microphone  318 , short-range communications  322 , and other device subsystems  324 . The short-range communications  322  can implement any suitable or desirable device-to-device or peer-to-peer communications protocol capable of communicating at a relatively short range, e.g. directly from one device to another. Examples include “BLUETOOTH”, ad-hoc WiFi, infrared, or any “long-range” protocol re-configured to utilize available short-range components. It will therefore be appreciated that short-range communications  322  may represent any hardware, software or combination of both that enable a communication protocol to be implemented between devices or entities in a short range scenario, such protocol being standard or proprietary. 
         [0023]    Some of the subsystems of the communication unit  300  perform communication-related functions, whereas other subsystems may provide “resident” or on-device functions. By way of example, the display  310  and the keyboard  316  may be used for both communication-related functions, such as entering a text message for transmission over the network  350 , and device-resident functions such as a calculator or task list. 
         [0024]    The communication unit  300  can send and receive communication signals over the wireless network  350  after required network registration or activation procedures have been completed. Network access is associated with a subscriber or user of the communication unit  300 . To identify a subscriber, the communication unit  300  may use a subscriber module component or “smart card”  326 , such as a Subscriber Identity Module (SIM), a Removable User Identity Module (RUIM) and a Universal Subscriber Identity Module (USIM). In the example shown, a SIM/RUIM/USIM  326  can be inserted into a SIM/RUIM/USIM interface  328  in order to communicate with a network. Without the component  326 , the communication unit  300  is not fully operational for communication with the wireless network  350 . Once the SIM/RUIM/USIM  326  is inserted into the SIM/RUIM/USIM interface  328 , it is coupled to the main processor  302 . 
         [0025]    The communication unit  300  is typically a battery-powered device and in this example includes a battery interface  332  for receiving one or more rechargeable batteries  330 . In at least some embodiments, the battery  330  can be a smart battery with an embedded microprocessor. The battery interface  332  is coupled to a regulator (not shown), which assists the battery  330  in providing power V+ to the communication unit  300 . Although current technology makes use of a battery, future technologies such as micro fuel cells may provide the power to the communication unit  300 . 
         [0026]    In the examples described herein, the communication unit  300  comprises or otherwise has access to a cryptographic processor  323  which can be embodied in hardware, software, or a combination of the two. Also, as will be discussed below, the cryptographic processor  323  may control or include a software-based cryptographic module or application that cryptographically processes data. The communication unit  300  may also comprise internal or external memory or other machine-readable media for storing executable instructions that may be executed by the processor(s)  302  including, but not limited to, enabling the cryptographic processor  323  to perform cryptographic operations as is known in the art. As can be seen in  FIG. 3 , the cryptographic processor  323  may be independent of the main processor  302  in a mobile device configuration, or may be implemented by special instructions or hardware associated with the main processor  302  itself. 
         [0027]    The communication unit  300  may also optionally include an operating system  334  and a plurality of software components  336 ,  338 . The operating system  334  and the software components  336 ,  338  that are executed by the main processor  302  are typically stored in a persistent or non-volatile store such as the flash memory  308 , which may alternatively be a read-only memory (ROM) or similar storage element (not shown). Those skilled in the art will appreciate that portions of the operating system  334  and the software components  336 ,  338 , such as specific device applications, or parts thereof, may be temporarily loaded into a volatile storage devices such as the RAM  306 . Other software components can also be included, as is well known to those skilled in the art. 
         [0028]    The data port  314  can be any suitable port that enables data communication between the communication unit  300  and another computing device. The data port  314  can be a serial or a parallel port. In some instances, the data port  314  can be a USB (Universal Serial Bus) port that includes data lines for data transfer and a supply line that can provide a charging current to charge the battery  330  of the communication unit  300 . 
         [0029]    For voice communications, received signals are output to the speaker  320 , and signals for transmission are generated by the microphone  318 . Although voice or audio signal output is accomplished primarily through the speaker  320 , the display  310  can also be used to provide additional information such as the identity of a calling party, duration of a voice call, or other voice call related information. 
         [0030]    For composing data items, such as e-mail messages, for example, a user or subscriber could use a touch-sensitive overlay (not shown) on the display  310  that is part of a touch screen display (not shown), in addition to possibly the auxiliary I/O subsystem  312 . The auxiliary I/O subsystem  312  may include devices such as: a mouse, track ball, infrared fingerprint detector, or a roller wheel with dynamic button pressing capability. A composed item may be transmitted over the wireless network  350  through the communication subsystem  304 . 
         [0031]    As noted above, the software applications  336 ,  338  stored in flash memory  308  (or the like) may include a cryptographic module that comprises or otherwise has access to a portion of memory, database or other data storage device for the storage of any data or information associated with the cryptographic capabilities of various communication units, as described in further detail below. 
         [0032]    It will be appreciated that any module or component exemplified herein that executes instructions may include or otherwise have access to computer readable media such as storage media, computer storage media, or data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Computer storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. Examples of computer storage media include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by an application, module, or both. Any such computer storage media may be part of the communication unit  300  or accessible or connectable thereto. Any processing described herein may be implemented using computer readable/executable instructions that may be stored or otherwise held by such computer readable media. 
         [0033]    Furthermore, while the communication unit  300  has been described herein primarily in terms of a mobile, wireless device, the instant disclosure is not necessarily limited in this regard. In particular, as used herein, a communication unit may comprise some lesser level of hardware, software or functionality than that described relative to  FIG. 3  without departing from the basic communication capabilities described above. For example, where physical objects are equipped with communication capability that does not require voice communications (as in the case, for example, of a device operating within the so-called Internet of Things (IoT)), components such as the microphone  318 , speaker  320 , etc. may be excluded from the communication unit integral to or embedded within such physical objects. As another example, such physical objects may have access to convention mains power that may be used to provide power to the communication unit, thereby obviating the need for the battery  330  or battery interface  332 . As yet another example, rather than relying on a wireless communication subsystem  304  or wireless short-range communications  322 , the communication unit could be equipped with a wired communication subsystem in order to interface with, for example, the public switched telephone network (PSTN). Those having skill in the art that other forms of embedded or integrated communication units that remain capable of performing the processing described herein may be employed as a matter of design choice. 
         [0034]    Various processing operations in accordance with the instant disclosure are described below with reference to  FIGS. 4-19 . As used herein, including the descriptions below, an initiating communication unit comprises any communication unit that generates a request to initiate communications—whether voice or data—with another communication unit. Oppositely, a target communication unit comprises an communication unit that receives, from another communication unit, a request to initiate communications of any type with that other communication unit. An intermediate communication unit comprises a communication unit that minimally has an already-existing, verified connection with an initiating communication unit and, in some embodiments described below, may further have a verified connection with a target unit associated with the initiating communication unit. Furthermore, a connection between two communication units may comprise not only a “physical” communication channel (as needed) but also a logical channel in which communications between the endpoints of the connection experience the benefits of a ZRTP-type connection, i.e., shared secrets known to the endpoints, session key continuity, ephemeral session keys, etc. In particular, and as used herein, a given connection and a shared secret established at the time of that connection&#39;s creation are assumed to correspond to each other such the reference to one is assumed to imply the other. 
         [0035]    Referring now to  FIG. 4 , verification processing by an initiating communication unit is further described. That is, the processing illustrated in  FIG. 4  concerns those steps taken by an initiating communication unit to verify a connection with a target communication unit. Thus, beginning at block  402 , the initiating communication unit establishes a first connection with a target communication unit, including establishment of a first shared secret known to both the initiating and target communication units. For example, in an embodiment, the initiating and target communication units may employ the Ephemeral Elliptic Curve, Diffie-Hellman Exchange (ECDHE) key negotiation process used in ZRTP to create an encryption key known to both the initiating and target communication units, referred to herein as a shared secret. As described above, each pairwise association of an initiating and target communication unit may utilize this approach to establish shared secrets therebetween. Consequently, each connection between two communication units may have a shared secret associated therewith and, in practice, any given communication unit in this scenario will thus maintain a plurality of shared secrets for each such connection that it may have. Although the ECDHE key negotiation process noted above may be employed for the establishment of shared secrets, those having skill in the art will appreciate that this is not a requirement as any suitable technique that similarly results in shared secrets may be employed. 
         [0036]    Referring once again to  FIG. 4 , processing continues at block  404  where the initiating communication unit creates a first message based on the first shared secret. Because the first shared secret is also known to the target communication unit, it should be able to successfully interpret the first message. In an embodiment, the first message may actually comprise a first encrypted message in which plaintext is encrypted based on a suitable encryption technique (such as, but not limited to, Authenticated Encryption with Associated Data (AEAD)) and the first shared secret. Additionally, the first message may also comprise a message authentication code (MAC) based on the first message (whether in plaintext or ciphertext form) and the first shared secret. For example, MACs used for this purpose may comprise Hash-Based Authentication Codes, though the instant disclosure is not limited in this regard. Regardless, thereafter at block  406 , the initiating communication unit sends the first message to at least one intermediate communication unit, wherein each of the at least one intermediate communication unit has a corresponding connection that has been previously designated by the initiating communication unit as being verified. By sending the first message to one or more intermediate communication units, the initiating communication unit is essentially attempting to use the verified connections already existing in the network to act as a trusted second (or back) channel to the target communication unit in an effort to automatically verify the target communication unit. An example of this is illustrate in  FIG. 6 . 
         [0037]    In  FIG. 6 , a simplified network of communication units (labeled “Alice,” “Bob,” “Charlie” and “Dawn”) is shown in which authenticated and verified connections between Alice and Bob, Alice and Charlie, Bob and Charlie and Alice and Dawn are assumed to have been previously established. It is noted that  FIGS. 6-8  (as well as  FIGS. 13-19 ) employ a convention in which circles associated with a given communication unit and terminating a connection are used to illustrate the fact that the communication unit associated with a circle has been authenticated to the other communication unit terminating that connection. In turn, squares used in this manner indicate that the associated communication unit has not been authenticated to the other communication unit terminating that connection. Further still, shading or cross-hatching of these connection terminators—whether squares or circles—indicates that the associated communication unit has not yet designated the connection as being verified, whereas solid white connection terminators indicate that the associated communication has designated the connection as being verified. In implementation, the designation of a connection as being verified or the designation of a communication as being authenticated may be performed through the setting of an appropriate value corresponding to the relevant connection/shared secret and/or communication unit in a persistent memory location implemented by the designating communication unit. 
         [0038]    For example, in  FIG. 6 , the pre-existing, authenticated and verified Alice-Bob, Alice-Charlie and Bob-Charlie connections are illustrated as being terminated by solid, white circles. In contrast, the newly established Dawn-Charlie connection (as described above at block  402 ) is illustrated with shaded, square connection terminators, indicating the fact that the neither Dawn or Charlie have yet verified the connection, and that Dawn has not yet been authenticated to Charlie and vice-versa. In this example, in which it is assumed that Dawn is the initiating communication unit and Charlie is the target communication unit, the sole intermediate communication unit available to Dawn is Alice. In practice, however, it is likely that any given communication unit will, over time, have multiple such intermediate communication units available, e.g., Alice and Charlie are both intermediate communication units to Bob. Regardless, having established the unverified connection with Charlie, Dawn sends a first message (as described above) to Alice. Alice, as an intermediate communication unit, will process the first message in order to determine whether it (Alice) was the intended recipient of the first message or, if not, whether to forward the first message on to other communication units in the network having validated connections with Alice (described in further detail below with reference to  FIG. 5 ). 
         [0039]    Referring once again to  FIG. 4 , from the point of view of the initiating communication unit and subsequent to sending the first message to the at least one intermediate communication unit, a second message is received from the at least one intermediate communication unit at block  408 . At block  410 , the initiating communication unit interprets the second message based on the shared secret. As used herein, interpretation of a message based on a shared secret means that the communication unit attempts to determine whether the message was originally created in accordance with that shared secret. For example, in the case of the second message comprising ciphertext, interpretation of the second encrypted message comprises attempting to decrypt the message based on the shared secret. In this case, the message is successfully interpreted if the resulting plaintext is understandable. As another example, where the second message comprises a received message authentication code determined according to the shared secret, the communication unit may determine a computed message authentication code based on the received second message (whether encrypted or not) and the shared secret. A comparison is then made between the received and computed message authentication codes. If the received and computed message authentication codes match, then the second message is deemed successfully interpreted. Other interpretation schemes of the type described here will be apparent to those having skill in the art. 
         [0040]    Thus, at block  412 , a determination is made whether the second message has been successfully interpreted based on the first shared secret. If not, then processing continues at block  414  where the second message is further processed as in the case that the initiating communication unit is serving in the role of an intermediate communication unit, as described in further detail below. If the second message is successfully interpreted at block  412 , processing continues at block  416  where the first connection between the initiating and target communication units is designated by the initiating communication unit as being verified. 
         [0041]    An example of this is further illustrated with reference to  FIGS. 7 and 8 . In  FIG. 7 , Alice, acting as the intermediate communication unit sends the second message (originated by the target communication unit, Charlie, after receiving and successfully interpreting the first message sent by Dawn, as described in further detail below) to Dawn. In turn, when Dawn successfully interprets the second message based on the first shared secret, Dawn designates the connection with Charlie as being verified. This is illustrated in  FIG. 8  where the connection terminator for Dawn terminating the connection with Charlie is now illustrated without the shading. Note that Dawn&#39;s terminator for the connection with Charlie is still illustrated as a square in this case as Charlie has not yet been authenticated to Dawn. 
         [0042]    Referring now to  FIG. 5 , verification processing by an intermediate communication unit is further described. That is, the processing illustrated in  FIG. 5  concerns those steps taken by an intermediate communication unit to verify a connection with a target communication unit. A particular feature of the processing performed by any communication unit that receives a message for purposes of verification is that such communication unit will operate as an intermediate communication unit until such time as it determines that it is, in fact, the target communication unit for that message. In this sense, the description of various communication units as initiating, intermediate or target communication units is a labeling convention employed for ease of explanation. In practice, the circumstances concerning each determination of successful message interpretation determines the effective label to be applied to any given communication unit. 
         [0043]    With this in mind, processing begins at block  502  where an intermediate communication unit receives a first message from a first communication unit. Note that no assumption is made in  FIG. 5  that the first communication unit is an initiating communication unit, a target communication unit or even another intermediate communication unit. Thereafter, at block  504 , the intermediate communication unit attempt to interpret the first message based on at least one shared secret in its possession. Thereafter, at block  506 , a determination is made if any of the at least one shared secrets maintained by the intermediate communication unit were successfully employed to interpret the first message. If none of the shared secrets were successful, then processing continues at block  508  where the intermediate communication unit sends the first message to at least one second intermediate communication unit where, once again, each of the at least one second intermediate communication units has a connection with the intermediate communication unit previously designated by the intermediate communication unit as being verified. An example of this is illustrated in  FIG. 6 . 
         [0044]    In  FIG. 6 , Alice, as the intermediate communication unit receives the first message from Dawn. Being unable to successfully interpret the first message based on any shared secrets in its possession, Alice then forwards the first message to those communication units having connections with Alice that Alice has previously designated as verified, i.e., Bob and Charlie. Bob and Charlie, in turn, will likewise operate as intermediate communication units, i.e., also in accordance with the processing illustrate in  FIG. 5 . In this sense, the authenticated connections within the network are acting in a “viral” manner to communicate the first message to its proper recipient, i.e., they route the message within the boundaries of any verified connections in the network. As will be appreciated by those of skill in the art, well-known time to live (TTL) mechanisms, such as hop counters or time stamps, may be employed to prevent messages as described herein from indefinitely propagating through the network&#39;s verified connections. 
         [0045]    Referring once again to  FIG. 5 , if the determination is made at block  506  that one of the shared secrets maintained by the intermediate communication unit was successful at interpreting the first message, then the intermediate effectively knows at this point that it was the intended recipient (i.e., the target communication unit) of the first message. Thus, it is further determined at block  510  whether a connection corresponding to the successful shared secret (i.e., that shared secret that was able to successfully interpret the first message) has been previously verified. In other words, it may be that the first message is actually an attempt by another communication unit (corresponding to the successful shared secret and associated connection) to verify its connection with the given “intermediate” communication unit. If it is determined at block  510  that the connection corresponding to the successful shared secret has previously been designated as verified, the processing continues at block  512  where the first message is further processed at the intermediate (now, effectively deemed the target) communication unit in the sense that the first message is handled according to its type. For example, in the case that the first message comprises a text message or the like intended for the user of the intermediate (target) communication unit, the processing at block  512  may comprise rendering the text message on a display of the intermediate (target) communication unit. 
         [0046]    On the other hand, if it is determined at block  510  that the connection corresponding to the successful shared secret has not been previously verified, then processing continues at block  514 . In this case, then, the first message is an attempt by another communication unit to verify its connection with the intermediate (target) communication unit. Thus, at block  514 , the intermediate (target) communication unit designates the connection corresponding to the successful shared secret as being verified and, at block  516 , further processes the first message in the same manner, as necessary, as described above relative to block  512 . An example of this is illustrate in  FIGS. 6 and 7 , where Charlie, after receiving and successfully interpreting the first message ( FIG. 6 ), subsequently designates the connection with Dawn as being verified. Once again, this is illustrated in  FIG. 7  where the connection terminator for Charlie terminating the connection with Dawn is now illustrated without the shading. Once again, it is noted that Charlie&#39;s terminator for the connection with Dawn is still illustrated as a square because Dawn has not yet been authenticated to Charlie. 
         [0047]    As noted previously with regard to  FIG. 4 , part of the verification process for the initiating communication unit is receiving a similar verification message from the target communication unit to order to verify the corresponding connection from the initiating communication unit&#39;s point of view. This is illustrated in  FIG. 5  at blocks  518  and  520 . At block  518 , the intermediate (target) communication unit creates a second message based on the successful shared secret and, at block  520 , sends the second message to at least one selected intermediate communication unit where, once again, each of the at least one selected intermediate communication units has a connection with the intermediate (target) communication unit previously designated by the intermediate (target) communication unit as being verified. In an embodiment, the at least one selected intermediate communication unit may include an intermediate communication unit other than the one from which the first message was received, which can improve overall security in the event of a potentially compromised intermediate communication unit. An example of this is illustrated in  FIG. 7  where, Charlie, having determined that it was the target communication unit of the first message sent by Dawn ( FIG. 6 ), sends a second message to Alice and Bob. As shown, the at least one selected intermediate communication unit will, at minimum, include the intermediate communication unit from which the first message was received, i.e., Alice. However, as further shown in  FIG. 7 , the at least one selected intermediate communication unit can include other intermediate communication units from which the first message was not received, i.e., Bob. 
         [0048]    The techniques illustrated with reference to  FIGS. 4-8  describe the use of verified connections within a network of communication units in order to automatically verify new connections within the network. However, as noted in the examples of  FIGS. 6-8 , verification of a connection does not necessarily lead to authentication of one communication unit to another. To the end, further processing for the purpose of authenticating communication units is further described below with reference to  FIGS. 9-19 . 
         [0049]    Referring now to  FIG. 9 , authentication processing by an initiating communication unit is further described. That is, the processing illustrated in  FIG. 9  concerns those steps taken by an initiating communication unit to authenticate a target communication unit and, optionally, to authenticate itself back to the target communication unit. Thus, at block  902 , the initiating communication unit identifies a first intermediate communication unit that may be employed in the verification process. Various techniques for accomplishing this may be used. For example, a process for identifying the first intermediate communication unit is further illustrated in  FIG. 10 . At block  1002 , the initiating communication unit sends a request to the target communication unit for a list of authenticated peers (communication units). In response, the initiating communication unit receives a first list of authenticated communication units from the target communication unit at block  1004 . The first list of authenticated communication units includes identifications of those communication units that have been previously authenticated to the target communication unit. At block  1006 , processing continues where the initiating communication unit compares the first list of authenticated communication units with a second list of communication units that have been previously authenticated to the initiating communication unit. At block  1008 , the initiating communication unit determines whether an identification of any communication unit in the first list matches an identification of any communication unit in the second list. If not, processing continues at block  1010  where an indication may be provided of the inability to authenticate at this time. If at least one identification of a communication unit in the first list is matched in the second list, indicating that the identified communication unit is already authenticated to both the initiating and target communication units, the initiating communication unit selects the matched identification as the first intermediate communication unit at block  1012 . In an embodiment, bi-directional authentication between the initiating and target communication units and the communication units in their respective lists is presumed, i.e., the target communication unit is authenticated to each of the communication units in the first list and the initiating communication unit is authenticated to each of the communication units in the second list. However, this is not a requirement and the instant disclosure is not limited in this regard. Though  FIG. 10  illustrates a particular technique that permits the initiating communication unit to identify an intermediate communication unit, the instant disclosure is not limited in this regard and other techniques may be employed for this purpose. 
         [0050]    An example of this is illustrated in  FIG. 13  (which represents a continuation of the illustration in  FIG. 8 ) where the initiating communication unit, Dawn, sends a request for the list of authenticated peers to the target communication unit, Charlie. In response, Charlie sends the first list back to Dawn, as shown. Note that, at this point, the connector terminators for the connection between Dawn and Charlie, shown as squares, reflect the fact that neither Dawn or Charlie is authenticated to the other. 
         [0051]    Referring once again to  FIG. 9 , having identified the first intermediate communication unit, processing continues at block  904  where the initiating communication unit sends a first authentication request to the first intermediate communication unit. In an embodiment, the first authentication request includes an identifier of the target communication unit that the initiating communication unit seeks to authenticate. In response, at block  906 , the initiating communication unit receives at least a first authentication answer to a first authentication problem generated by the intermediate communication unit. As described in greater detail below, the first authentication problem comprises a message that poses a question to the target communication unit and that the target communication unit is capable of successfully interpreting based on a shared secret that the target communication unit shares with the intermediate communication unit. In an embodiment, the intermediate communication unit sends the first authentication problem to the target communication unit responsive to the first authentication request. In an alternative embodiment, the initiating communication unit may instead receive, at block  908 , the first authentication problem from the intermediate communication unit and, at block  910 , forward the first authentication problem to the target communication unit. These alternative embodiments are further illustrated in  FIGS. 14 and 15 . In  FIG. 14 , the initiating communication unit, Dawn, sends the first authentication request to the first intermediate communication unit, Alice. In turn, in this case, Alice direct provides the first authentication problem to Charlie and further sends the first authentication answer to Dawn. In keeping with the alternate embodiment,  FIG. 15  illustrates the case where, in response to the first authentication request, Alice instead sends both the first authentication problem and the first authentication answer to Dawn. In this case, Dawn then sends the first authentication problem to Charlie. 
         [0052]    As noted, the first authentication problem poses a question that the target communication unit is capable of answering based on the share secret it shares with the intermediate communication unit. In this manner, and with reference to  FIG. 14  et seq., Alice is essentially telling Dawn that, if Charlie can provide you the correct answer to the first authentication problem, then that Charlie is the same at the Charlie that has been authenticated to Alice. Generally, the first authentication problem may take on a variety of forms that fit this need. For example, a naïve authentication problem can be an encrypted message. If Charlie can decrypt the ciphertext, C, to get plaintext, P, then Charlie answers correctly. Similarly, the authentication problem could be a MAC over a string, S, such that Charlie is asked to likewise provide the MAC of string S. However, such simple approaches are relative weak and vulnerable to cryptanalytic attacks. 
         [0053]    Preferably, the authentication problem meets a number of criteria. First, the authentication problem should not reveal the shared secret between the initiating and target communication units. Additionally, the authentication problem should be tailored by the intermediate communication unit for the initiating intermediate communication unit. That is, the target communication unit must know that the intermediate communication unit is posing the authentication problem on behalf of the initiating communication unit. Furthermore, the authentication problem should be reasonably immune to replays over time, i.e., it should incorporate a TTL mechanism. Further still, the intermediate communication unit shouldn&#39;t be able to help the target communication unit fraudulently authenticate. One potential mitigation would be to indicate a stronger authentication scheme based on the number of different authentication problems from different intermediate communication units. That is, in some instances, a stronger degree of authentication can be achieved, and any potential fraud by an intermediate communication unit is mitigated, if authentication problems from multiple intermediate communication units are employed. 
         [0054]    In the general case, the authentication problem, P, contains a set of parameters, and an answer, A, that is a bit string that represents the answer. An example of a construction of an authentication problem is a data structure that comprises the elements listed in Table 1 below. 
         [0000]    
       
         
               
               
             
           
               
                 TABLE 1 
               
               
                   
               
               
                 ELEMENT 
                 DESCRIPTION 
               
               
                   
               
             
             
               
                 Random Salt 
                 A random bitstring or suitable constant that the intermediate 
               
               
                   
                 communication unit includes to randomize any hashing. 
               
               
                 Version Number 
                 Version number for the data structure embodying the authentication 
               
               
                   
                 problem. 
               
               
                 Cryptographic 
                 An identifier of a cryptographic algorithm that will be used to compute 
               
               
                 Algorithm Identifier 
                 the authentication problem answer. For example, where the answer is a 
               
               
                   
                 MAC, this field could specify HMAC/Skein-51-512. 
               
               
                 Authentication 
                 Identifier of the communication unit that is creating the authentication 
               
               
                 Problem Creator 
                 problem on behalf of the initiating communication unit, i.e., the 
               
               
                 Identifier 
                 intermediate communication unit. 
               
               
                 Authentication 
                 Identifier of the communication unit that issued the authentication 
               
               
                 Problem Requestor 
                 request, i.e., the initiating communication unit. 
               
               
                 TTL 
                 Indicator of when the authentication problem was created. 
               
               
                 MAC 
                 A MAC that is computed using the specified algorithm over the whole 
               
               
                   
                 of the preceding fields in the data structure and based on the shared 
               
               
                   
                 secret between the initiating and target communication units. 
               
               
                   
               
             
          
         
       
     
         [0055]    In this case, the authentication problem answer is a MAC computed, using the noted algorithm, over the entirety of the data structure of Table 1, including the final MAC element listed in Table 1. 
         [0056]    Regardless of the particular form of the first authentication problem and how it is ultimately provided to the target communication unit, processing continues at block  912  where the initiating communication unit receives a first proposed answer from the target communication unit. An example of this is illustrated in  FIG. 16  where Charlie sends the first proposed answer (in response to the provided first authentication problem) directly to Dawn. In an embodiment, a message descriptor or similar mechanism may be used to identify the message received by Dawn as a proposed answer. Thereafter, at block  914 , the initiating communication unit compares the first authentication answer (previously received from the intermediate communication unit) with the first proposed authentication answer. If the two answers do not match at block  914 , processing continues at block  916  where an indication of a failed authentication may be provided. If the two answers do match at block  914 , the initiating communication unit designates the target communication unit as being authenticated. This is illustrated in  FIG. 16  where the connection terminator associated with Dawn is changed to a circle, indicating that the target communication unit for this connection, i.e., Charlie, has been authenticated to Dawn. It is noted that, at this point, the initiating communication unit, Dawn, is not yet authenticated to Charlie as indicated by the square-shaped connection terminator associated with Charlie. 
         [0057]    To complete the authentication of the initiating communication unit to the target communication unit, if needed or desired, processing optionally continues at blocks  920 - 924  where roles of the initiating and target communication units as described above relative to  FIG. 9  are reversed. That is, at block  920 , the initiating communication unit receives a second authentication problem, preferably structurally and functionally equivalent to the first authentication problem as described above, from the first intermediate communication unit or another intermediate communication unit. In this case, the second authentication problem is configured to be answered specifically by the initiating communication unit. Thus, at block  922 , the initiating communication unit determines an answer to the second authentication problem and, at block  924 , sends the resulting second proposed answer back to the target communication unit. The largely complementary operation of the target communication unit during authentication operation is further described below with reference to  FIG. 11 . 
         [0058]    Referring now to  FIG. 11 , authentication processing by a target communication unit is further described. That is, the processing illustrated in  FIG. 11  concerns those steps taken by a target communication unit to authenticate itself to an initiating communication unit and, optionally, to authenticate the initiating communication unit back to the target communication unit. Thus, the complementary steps to the process for identifying the first intermediate communication unit are illustrated at steps  1102  and  1104 . Particularly, at block  1102 , the target communication unit receives the request for the list of authenticated peers from the initiating communication unit and, at block  1104 , the target communication unit sends the first list of authenticated communication units to the initiating communication unit. Thereafter, at block  1106 , the target communication unit receives the first authentication problem from either the first intermediate communication unit or the initiating communication unit. At block  1108 , the target communication unit determines a first proposed answer to the first authentication problem as described above and, at block  1110 , sends the first proposed answer to the initiating communication unit. Presuming that the first proposed answer is correct, the target communication unit will be authenticated to the initiating communication unit as described above relative to  FIG. 9 . 
         [0059]    To complete the authentication of the initiating communication unit to the target communication unit, if needed or desired, processing optionally continues at blocks  1112 - 1126  where roles of the initiating and target communication units as described above relative to  FIG. 9  are reversed. Thus, the processing of blocks  1112 - 1126  are essentially the same as the processing of blocks  902 - 918  with the roles of the initiating and target communication units reversed. Thus, at block  1112 , a selected intermediate communication unit can be identified using essentially the same process as described above relative to  FIG. 10 . It is noted that the selected intermediate communication unit can be the same as the first intermediate communication unit, though this is not a requirement. Thereafter, at block  1114 , the target communication unit sends a second authentication request to the selected intermediate communication unit, which second authentication request includes an identifier of the initiating communication unit. In response, the target communication unit receives from the selected intermediate communication unit, at block  1116 , at least a second authentication answer to a second authentication problem and, optionally, the second authentication problem as well. When the target communication unit receives the second authentication problem from the selected intermediate communication unit, processing continues at block  1118  where the target communication unit sends the second authentication problem to the initiating communication unit. As described above, the selected intermediate communication unit could alternatively send the second authentication problem directly to the initiating communication unit. These alternatives are illustrated in  FIGS. 17 and 18 . In  FIG. 17 , the target communication unit, Charlie, sends the second authentication request to Alice and, in response Alice sends the second authentication answer to Charlie and the second authentication problem to the initiating communication unit, Dawn. Alternatively, in  FIG. 18 , in response to the second authentication request, Alice sends the both the second authentication answer and the second authentication problem to Charlie, and Charlie in turn sends the second authentication problem to Dawn. 
         [0060]    Regardless of how the initiating communication unit receives the second authentication problem, at block  1120 , the target communication unit receives a second proposed answer from the initiating communication unit. At block  1124 , the target communication unit determines if the second proposed answer compares favorably (i.e., matches) the second authentication answer. If not, processing continues at block  1126 , where an indication of a failed authentication may be provided. If the comparison is favorable, processing continues at block  1128  where the target communication unit designates the initiating communication unit as being authenticated. This is illustrated in  FIG. 19  where, in response to the second proposed answer received from Dawn, Charlie designates Dawn as being authenticated as indicated by the square connection terminator associate with Charlie. At this time, then, the connection between Dawn and Charlie has been verified and authenticated by both communication units. 
         [0061]    Finally, with reference to  FIG. 12 , authentication processing by an intermediate communication unit is further described. That is, the processing illustrated in  FIG. 12  concerns those steps taken by an intermediate communication unit to assist in the authentication of a target communication unit to an initiating communication unit and, optionally, vice versa. Thus, at block  1202 , the intermediate communication unit receive the first authentication request from the initiating communication unit, which request includes an identifier of the target communication unit. In response, the intermediate communication unit generates a first authentication problem and a first authentication answer, as described above, based on the identifier of the target communication unit. That is, based on the identifier of the target communication unit, the intermediate communication unit knows to use it shared secret for the target communication unit when constructing the first authentication problem and first authentication answer. At block  1206 , the intermediate communication unit sends the first authentication answer to the initiating communication unit. Thereafter, processing may proceed along either of two parallel paths denoted by blocks  1208  and  1210 . At block  1208 , the intermediate communication unit sends the first authentication problem to the target communication unit whereas, at block  1210 , the intermediate communication unit sends the first authentication problem to the initiating communication unit. 
         [0062]    In order to facilitate the opposite verification process, i.e., verification of the initiating communication unit to the target communication unit, the processing of blocks  1202 - 1210  is repeated with the roles reversed at blocks  1212 - 1220 . For the sake of convenience, it is assumed the first intermediate communication unit, as described relative to  FIG. 9  and the selected intermediate communication unit, as described relative to  FIG. 11 , are the same intermediate communication unit in  FIG. 12 . However, in practice, as noted previously, this is not a requirement and the separate processing of blocks  1202 - 1210  and blocks  1212 - 1220  could be performed by separate intermediate communication units. Regardless, at block  1212 , the intermediate communication unit receives a second authentication request from the target communication unit and, in response thereto, generates a second authentication problem and a second authentication answer at block  1214 . As before, the intermediate communication unit sends the second authentication answer to the target communication unit at block  1216 . Thereafter, processing may proceed along either of two parallel paths denoted by blocks  1218  and  1220 . At block  1218 , the intermediate communication unit sends the second authentication problem to the intermediate communication unit whereas, at block  1220 , the intermediate communication unit sends the first authentication problem to the target communication unit. 
         [0063]    While particular preferred embodiments have been shown and described, those skilled in the art will appreciate that changes and modifications may be made without departing from the instant teachings. It is therefore contemplated that any and all modifications, variations or equivalents of the above-described teachings fall within the scope of the basic underlying principles disclosed above and claimed herein.