Abstract:
In a wireless network, secure synchronization may be achieved with two messages. A beacon initiator may provide a beacon timestamp field and a beacon nonce to devices in the network. A device in the network that wishes to synchronize with another device may send a message containing a variety of parameters including the beacon timestamp field and the nonce. Upon receipt, the receiving device can check a key included in the message, the beacon timestamp field and the nonce to determine, not only that the sender has a valid key, but that the message has a valid time so that one can be reasonably sure that the message was not simply copied. The receiving device then sends a message response which contains verifiable parameters to enable the message sender to be sure that the sender is communicating with a valid receiver.

Description:
BACKGROUND  
         [0001]    This invention relates generally to networks which are established pursuant to wireless protocols.  
           [0002]    A variety of wireless protocols enable short-range wireless networks between processor-based and non-processor-based systems. A station in one network may be mobile and may be moved from area to area so that it eventually interacts with one or more networks. Before a network may wish to communicate with an in-range mobile station, a network may wish to authenticate the mobile station to ensure that network security will not be compromised as a result of such communications.  
           [0003]    Thus, it would be desirable to have a relatively simple way to enable wireless devices to communicate with one another in a secure fashion. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0004]    [0004]FIG. 1 is a schematic depiction of one embodiment of the present invention; and  
         [0005]    [0005]FIG. 2 is a flow chart for one embodiment of the present invention. 
     
    
     DETAILED DESCRIPTION  
       [0006]    Referring to FIG. 1, a network  11  may include at least two devices  10   a  and  10   b  that communication over an appropriate wireless protocol. In one embodiment, that wireless protocol may be the IEEE 802.11 protocol. (ANSI/IEEE Std. 802.11, 1999 Edition), IEEE Standards Board, Piscataway, N.Y. 08855. Each device  10  may include an antenna  12  that may, for example, be a dipole antenna.  
         [0007]    Each communicating party  10   a  or  10   b  may be part of the same network. The parties  10   a  and  10   b  may be a station and an access point or they may be a pair of stations in an ad hoc network or a side-band channel or repeater, to mention a few examples. A wireless communication channel between the devices  10   a  and  10   b.    
         [0008]    Each of the devices  10   a  and  10   b  may receive a beacon frame or message  18  from a beacon initiator  10   c . Like the devices  10   a  and  10   b , the beacon initiator  10   c  may be any wireless device including a station, an access point, a side-band channel or repeater, to mention a few examples. The beacon initiator  10   c  may generate a beacon with a beacon timestamp field containing a copy of the timer syncronization function (TSF)  16  and nonce (N)  17 . The beacon initiator  10   c  may simply be a party that produces beacon messages pursuant to an 802.11 protocol. Each beacon message announces important protocols for the network and is typically broadcast to all the members of the network. Among the beacon parameters is a common notation of time, represented by the TFS  16 . For example, devices in an 802.11 network may synchronize to the network&#39;s notion of time within 4 microseconds.  
         [0009]    In accordance with one embodiment of the present invention, the beacon message  18  may also include a nonce “N”  17 . The beacon initiator  10   c  may establish its nonce  17  whenever it initializes and the initiator  10   c  uses its nonce  17  until the initiator  10   c  again reinitializes in one embodiment. The nonce  17  may be selected so it is never reused across any reinitialization of the beacon initiator  10   c  in one embodiment. Thus, the nonce value may be a real time wall clock value, a randomly generated value, or some other value that is not reused until the crytographic key used to protect the message exchanges is changed.  
         [0010]    When the device  10   a  wishes to establish a synchronized state with the device  10   b , the device  10   a  consults the latest beacon message  18  to learn the present TFS  16  and beacon nonce  17 . The device  10   a  then formulates a request message  20  to the device  10   b . The request message  20 , in one embodiment, may include the identity of the device  10   a  (“id A ”), the identity of device  10   b  (“id B ”), the state (“s”) that the device  10   a  wishes to synchronize to, its notion of time (“T”) based on the TFS  16 , the beacon nonce (“N”)  17 , the randomly generated nonce (“N A ”) from the device  10   a  and an electronic signature. The signature may be computed as a message integrity code (MIC).  
         [0011]    A cryptographically secure message integrity code can be used to sign data messages sent over an 802.11 channel. Examples of MICs include Hashing for Message Authentication-Secure Hash Algorithm (HMAC-SHA-1), See M. Bellare, et al., RFC 2104 (February 1997), Advanced Encryption Standard-Cipher Blocking Chaining-Message Authentication Code (AES-CBC-MAC), and Parallelizable MAC (PMAC). Any MIC may be used in accordance with some embodiments of the present invention.  
         [0012]    The devices  10   a  and  10   b  may share a key (“K”) utilized for data authentication. The key may be derived from a password, may be dynamically assigned, or may be generated in some other fashion. Generally, it is desirable that the key be distributed in a secure manner so that it is unknown to possible adversaries.  
         [0013]    Thus, in one embodiment, the signature may be computed as an MIC using the authentication key over the following data:  
         [0014]    A to B: id A ,id B ,s,T,N,N A ,MIC K (id A ,id B ,s,T,N,N A )  
         [0015]    The order of these message elements is immaterial, and some of the values may be implicit. In particular, the state s may be implicit or it may be only a reference to a state. It is, however, desirable in some embodiments that the device  10   a &#39;s own nonce N A  be unpredictable and, also, never be repeated during the lifetime of the key K.  
         [0016]    When the device  10   b  receives the request message  20 , it shares the authentication K with the party identified by id A . The device  10   b  then determines whether the request message&#39;s notion of time T matches its own. In other words, the device  10   b  determines whether the message  20  is sufficiently recent that the nonce N also matches the nonce presently used in beacon messages  18  and that the device  10   b  is the intended party in this synchronization protocol.  
         [0017]    The device  10   b  also uses the authentication key to verify the MIC signature over the request message  22 . If any of these checks fail, then the device  10   b  interprets the message as invalid and declines the request to synchronize the state s.  
         [0018]    However, if all of these checks succeed, the device  10   b  interprets the request message as valid. The device  10   b  can treat the request as valid because it contains the time T and the beacon nonce N, identifying this request message  20  as a recently generated message and confirms that the data has been protected by the MIC. By assumption, the key K is unknown to any adversary and the MIC is cryptographically secure, so it is computationally infeasible for an adversary to produce the message in the required time frame.  
         [0019]    When it receives a valid synchronization request message  20 , the device  10   b  formats and returns the response message  22 . The response message  22  may be similar to the request message  20 , except it may not include the time T and the beacon nonce N in one embodiment:  
         [0020]    B to A: id A ,id B ,s,N A ,MIC K (id A ,id B ,s,N A )  
         [0021]    When the device  10   a  receives the message  22 , it verifies that the response matches the request message  20  and that the message&#39;s MIC is correct. In particular, the device  10   a  verifies the timeliness of the request message  22  by checking the response message  22  including the nonce N A . If the request message  22  passes these tests, then the device  10   a  knows that it has synchronized the state s with the device  10   b . Moreover, it has done so with only two messages in some embodiments.  
         [0022]    As indicated in FIG. 1, each device  10   a  or  10   b  may include a storage  14   a  or  14   b  that may store code or software for implementing the secure two message synchronization protocol just described. In other embodiments the secure two message synchronization protocol may be implemented in hardware or logic.  
         [0023]    Thus, referring to FIG. 2, initially, on the left side, the device  10   a  establishes K, as indicated in block  28   a . Similarly, the device  10   b  establishes K, as indicated in block  28   b . Thus, both the devices  10   a  and  10   b  have the authentication key K.  
         [0024]    Next, a beacon message  18  may be provided to both devices  10   a  and  10   b . As a result, the TFS and the beacon nonce N may be established on each device  10 , as indicated in blocks  30   a  and  30   b . The device  10   a , which is the message initiator, initiates a request message  20  to synchronize s, as indicated in block  32 . As indicated by the arrow from block  32  to diamond  36 , the request may include the parameters id A , id B , s, T, N, N A , MIC K (id A , id B , s, T, N, N A ).  
         [0025]    When the request message  20  is received at device  10   b , the device  10   b  validates the message  20 , as indicated in diamond  36 , and provides a response message  22  to any valid requests. The response message may include the parameters id A , id B , s, N A , MIC K (id A , id B , s, N A ). When the device  10   a  receives the response message  22 , the device  10   a  validates the response, as indicated in diamond  34 .  
         [0026]    While the present invention has been described with respect to a limited number of embodiments, those skilled in the art will appreciate numerous modifications and variations therefrom. It is intended that the appended claims cover all such modifications and variations as fall within the true spirit and scope of this present invention.