Wireless device and method for rekeying with reduced packet loss for high-throughput wireless communications

Embodiments of a wireless device and methods for rekeying with reduced packet loss in a wireless network are generally described herein. In some embodiments, during rekeying operations a new key for reception may be installed early (i.e., prior to receipt of a rekeying confirmation message). The use of the new key for transmission may be delayed until after receipt of the rekeying confirmation message. The early installation of the new key for reception may allow both the new key and old key to be active at the same time for use decrypting received packets to reduce packet loss during rekeying operations. The rekeying confirmation message may be the fourth message of a four-way handshake for rekeying. In some embodiments, two key identifiers may be alternated between four-way handshakes to prevent deletion of the old key.

TECHNICAL FIELD

Embodiments pertain to wireless communications. Some embodiments pertain to rekeying operations in wireless networks. Some embodiments pertain to a four-way handshake for rekeying operations in accordance with one of the IEEE 802.11 standards. Some embodiments pertain to video streaming in high-throughput wireless networks.

BACKGROUND

In many wireless networks, packets are encrypted with encryption keys to provide security. Upon the occurrence of certain conditions, the encryption keys are renewed and new keys are generated. During the rekeying process, there may be a short period of time when the stations are using different keys. As a result, some of the packets are not able to be decrypted and have to be discarded. This loss of packets is particularly an issue in very high-throughput situations such as video streaming because it may result in a disruption in the video. This packet loss may also affect the slow start algorithm for the transmission control protocol (TCP).

Thus there are general needs for wireless devices and methods for rekeying with reduced packet loss suitable for very high-throughput wireless communications.

DETAILED DESCRIPTION

FIG. 1is a wireless communication network in accordance with some embodiments. Wireless communication network100may include two or more wireless devices, such as an authenticator102and a supplicant104. The authenticator102and the supplicant104may communicate through a wireless channel in accordance with one or more wireless communication techniques, such as one of the IEEE 802.11 communication standards. In some embodiments, the authenticator102may be an access point (AP) and the supplicant104may be a mobile station (STA).

The authenticator102and the supplicant104may communicate packets that are encrypted using encryption keys. The encryption keys may be generated during a successful authentication process between the authenticator102and the supplicant104. The encryption keys may be updated through a subsequent rekeying process between the authenticator102and the supplicant104. The rekeying process may include a four-way handshake described in more detail below.

In accordance with embodiments, to help reduce packet loss during rekeying operations, the authenticator102may install a new key for reception prior to receipt of a re-keying confirmation message. The authenticator102may also delay the use of the new key for transmission until after receipt of the re-keying confirmation message. In accordance with embodiments, the supplicant104may install the new key for reception prior to transmission of the rekeying confirmation message and may delay using the new key for transmission until after the transmission of the re-keying confirmation message. The early installation of the new key for reception by both the authenticator102and the supplicant104allows both the new key and old key to be active at the same time for use in decrypting received packets. In this way, packet loss during rekeying operations may be reduced. These embodiments are discussed in more detail below.

In some embodiments, the rekeying process may be part of a four-way handshake103, and the rekeying confirmation message may be the fourth message of the four-way handshake. In some embodiments, the new key may be an asymmetric key generated by both the supplicant104and the authenticator102from information exchanged during the four-way handshake. These embodiments are discussed in more detail below.

Conventionally, a new key is not installed and used by the authenticator102for reception until after receipt of the rekeying confirmation message. Conventionally, the new key is not installed and used by the supplicant104for reception until after transmission of the rekeying confirmation message. Because these events are not synchronized, some packets received before completion of the rekeying process may not be able to be properly decrypted. In accordance with some embodiments, the early installation and use of the new key for reception and the continued support of the old key for reception allows packets that were encrypted with either the old key or the new key to be properly decrypted. Unlike conventional rekeying techniques, two or more keys for reception may be active at the same time and may be used for decrypting received packets.

The Institute for Electrical and Electronic Engineer's (IEEE) 802.11i draft standard defines a protocol (802.11i protocol) for establishing mutual authentication and unicast group keys between a mobile station and its associated access point. The 802.11i protocol uses the four-way handshake to verify session liveliness to establish a unicast key and to establish a group key. Some embodiments may be layered on top of the IEEE 802.11 four-way handshake to reduce packet loss that may occur during rekeying.

In some embodiments, the authenticator102is an access point and the supplicant104is a mobile station. In these embodiments, the access point and the mobile station may communicate in accordance with one of the IEEE 802.11 communication standards or draft standards. In some embodiments, the rekeying operations may be performed during a communication session that includes a video-streaming session in which unicast packets are streamed from the access point to the mobile station. Although the authenticator102is described in some embodiments as an access point and the supplicant104is described in some embodiments as a mobile station, the scope of the embodiments is not limited in this respect. In some alternate embodiments, the authenticator may be a mobile station and the supplicant may be an access point. In other alternate embodiments, the authenticator and supplicant may both be mobile stations.

In some embodiments, key generation may be triggered by the pending lifetime expiry of an existing key. A key may expire after a predetermined period of time (e.g., 12 hours). Key generation may also be triggered by the pending exhaustion of the packet number. Each packet is assigned a packet number to detect replay attacks. The packet number is unique for each packet encrypted using a given key. If the packet number space is exhausted (i.e., all the packet numbers are assigned) then a new key is generated. Rekeying may be performed before any of these events occurs to prevent the security association from being broken.

FIG. 2illustrates a procedure for rekeying with reduced packet loss in accordance with some embodiments. In procedure200, the supplicant104and the authenticator102may have an established security association and may exchange packets using one or more encryption keys. Upon the occurrence of a rekeying event, the authenticator102may transmit a rekeying initiation message201to initiate the rekeying process in operation222. In response to receipt of the rekeying initiation message201, the supplicant104may transmit a rekeying initiation response message202to the authenticator102in operation242. The authenticator102may receive the rekeying initiation response message202in operation224. In response to receipt of the rekeying initiation response message202, the authenticator102may generate and install a new key for reception. The information transmitted in the rekeying initiation message201and received in the rekeying initiation response message202may be used to generate the new key.

In operation226, the authenticator102transmits a response validation message203in response to the rekeying initiation response message202. In operation244, the supplicant104receives the response validation message203and may generate and install the new key for reception prior to transmission of the rekeying confirmation message204. The response validation message203may demonstrate to the supplicant104that the exchange is not subject to a man-in-the-middle attack. Both the supplicant104and the authenticator102are able to generate the same new key because of the information exchanged.

In these embodiments, the authenticator102may install a new key for reception prior to transmission of the response validation message203, and the supplicant104may install the new key for reception prior to transmission of the rekeying confirmation message204. In this way, both the new key and the old key may be used for reception. These embodiments may be described in more detail below.

In some embodiments, after installing the new key for reception in operation224, the authenticator102may use either the new key or an old key for reception while continuing to use the old key for transmission in operation228. In operation244, the supplicant104may install the new key for reception prior to transmission of the rekeying confirmation message204and may delay using the new key for transmission until after the transmission of the rekeying confirmation message204.

During operation228, the authenticator102may use either the new key or an old key to decrypt packets received from the supplicant104beginning prior to receipt of the rekeying confirmation message204until a predetermined period of time after receipt of the rekeying confirmation message204. The authenticator102may also delay using the new key to encrypt packets for transmission to the supplicant104until after receipt of the rekeying confirmation message204. In some embodiments, the authenticator102may delay use of the new key for encrypting packets for transmission until immediately after receipt of the rekeying confirmation message204or until a predetermined period of time after receipt of the rekeying confirmation message204.

In some embodiments, the supplicant104may delay installing and/or using the new key for transmission in operation248until immediately after sending the rekeying confirmation message204in operation246or a predetermined period of time after sending the rekeying confirmation message204in operation246. In some alternate embodiments, the supplicant104may delay using the new key for transmission until a predetermined period of time after receipt of the response validation message203.

In some embodiments, after installing the new key in operation224for reception prior to receipt of the rekeying confirmation message204, the authenticator102may select either the new key or an old key for decrypting received unicast packets based on a key identifier carried in the received unicast packets. In these embodiments, the authenticator102may support receiving with the old key until receipt of the rekeying confirmation message204or until a predetermined period of time after receipt of the rekeying confirmation message204. In these embodiments, the supplicant104may support receiving with the old key until transmission of the rekeying confirmation message204in operation246or until a predetermined period of time after transmission of the rekeying confirmation message204in operation246. In some embodiments, the predetermined period of time may be approximately sixty seconds, although this is not a requirement.

In operation232, the authenticator102may transmit packets encrypted with the new key and may support receptions of packets with the old key and the new key. Similarly, in operation250, the supplicant104may transmit packets encrypted with the new key and may support receptions of packets with the old key and the new key.

In some embodiments, the rekeying initiation message201may be Message1(M1) of a four-way handshake103, the rekeying initiation response message202may be Message2(M2) of the four-way handshake103, the response validation message203may be Message3(M3) of the four-way handshake103and the rekeying confirmation message204may be Message4(M4) of the four-way handshake103. In these embodiments, the authenticator102may install the new key for use in decrypting received packets after receipt of Message2and prior to transmission of Message3. The authenticator102may also delay use of the new key for encrypting packets for transmission until after receipt of Message4. The supplicant104may install the new key for use in decrypting received messages after receipt of Message3and prior to transmission of Message4. The supplicant104may delay installing the new key for use in encrypting packets for transmission until either immediately after transmission of Message4or a predetermined period of time after transmission of Message4. Unlike the case for receiving that supports the concurrent use of two keys for reception, when the new key is installed for transmitting, the old key is no longer used for transmitting.

In operation234, the authenticator102may uninstall the new key if the four-way handshake103fails to complete. In operation252, the supplicant104may uninstall the new key if the four-way handshake103fails to complete. In these embodiments, both the authenticator102and the supplicant104may refrain from any further use of the new key for both reception and transmission if the four-way handshake103fails to complete. The authenticator102assumes success of the four-way handshake103on receipt of the rekeying confirmation message204and may send an acknowledgement (ACK)206to the supplicant104. The supplicant104may assume success of the four-way handshake103based on receipt of the acknowledgement206from the authenticator102.

In some embodiments, the four-way handshake103may comprise exchanging Extensible Authentication Protocol over Local area network (EAPOL) key frames in accordance with an IEEE 802.11 communication standard. In these embodiments, the four-way handshake103may be part of an Extensible Authentication Protocol (EAP) and the EAPOL key frames may be EAPOL key frames in accordance with the IEEE 802.11 communication standard. In some of these embodiments, the four-way handshake103may be performed in accordance with the IEEE 802.11n, IEEE 802.11 ac and/or IEEE 802.11 ad communication standards or proposed standards. In these embodiments, message one, message two, message three and message four may be EAPOL key frames with the key-type subfield set to one.

In some conventional rekeying processes, the installation of a new key with the same key ID as a previous key causes the previous key to be deleted as it is replaced by the new key. In some embodiments, two key IDs may be used, and each handshake may alternate between the two key IDs. For example, a first handshake may be done with a first key ID (e.g., Key ID=0) and the next handshake may be done with a second key ID (e.g., Key ID=1). In this way, two keys may be installed, allowing a smoother handover from one key to the other (e.g., the keys for receiving are installed and then later the key is used for transmitting). The next handshake (e.g., the third handshake) may be done with the first key ID (e.g., Key ID=0) replacing the old key using Key ID=0.

FIG. 3is a block diagram of a wireless device in accordance with some embodiments. Wireless device300may be suitable for use as either supplicant104(FIG. 1) or the authenticator102(FIG. 1). Wireless device300may include physical-layer circuitry302, processing circuitry304, and memory306. In accordance with embodiments, the processing circuitry304may perform rekeying operations and the memory306may have unicast key ID space to store at least two unicast keys for use in encrypting and decrypting packets that comprise unicast traffic. When the wireless device300operates as an authenticator102, the processing circuitry304may install a new key for reception prior to receipt of a rekeying confirmation message204and may delay use of the new key for transmission until after receipt of the rekeying confirmation message204. When the wireless device300operates as an authenticator102, the authenticator102continues to support the use of the old key for reception and the new key for reception for a predetermined period of time after receipt of the rekeying confirmation message204.

In these embodiments, when the wireless device300operates as a supplicant104, the processing circuitry304may install a new key for reception prior to transmission of the rekeying confirmation message204, and may delay use of the new key for transmission until after the transmission of the rekeying confirmation message204. When the wireless device300operates as the supplicant104, the supplicant104continues to support the use of the old key for reception and the new key for reception until a predetermined period of time after transmission of the rekeying confirmation message204.

In some embodiments, when supporting the use of both the new key and the old key for reception, the wireless device300may read a key ID field in a received unicast packet and may identify either the old key or the new key from the key ID field. The identified key may be used to decrypt the received unicast packet.

In some embodiments, the memory306may include non-unicast key ID space for one or more non-unicast (e.g., broadcast or multicast) keys. In these embodiments, the wireless device300may determine whether a received packet is either a unicast packet or a non-unicast packet based on a media-access control (MAC) address of the received packet. A non-unicast packet is a packet that is addressed to more than one recipient. A unicast packet is a packet that is addressed to one recipient. The wireless device300may index the unicast key ID space based on the key ID field to identify one of the unicast (e.g., pair-wise) keys when the received packet is a unicast packet. The wireless device300may index the non-unicast key ID space based on the key ID field to identify one of the non-unicast (i.e. group) keys when the received packet is a non-unicast packet. In these embodiments, the MAC address of the received packet may indicate whether the packet is a unicast or a non-unicast packet. When the packet is a unicast packet, a key from the unicast key space may be used for decrypting the received packet. When the packet is a non-unicast packet, a key from the non-unicast key space may be used for decrypting the received packet. The particular key may be selected from the key space based on the key ID. In some of these embodiments, the key ID for unicast packets may, for example, be either zero or one and may be used to index a key (e.g., either the old or the new key) in the unicast key space. The key ID for non-unicast packets may, for example, be zero, one, two or three, and may be used to index one of several keys in the non-unicast key space. The use of the MAC address may be used to determine which key space to index. Non-unicast packets, for example, may be broadcast or multicast packets. In these embodiments, when communications are performed in accordance with one of the IEEE 802.11 standards, the current definitions of key ID values of 0, 1, 2 and 3 in IEEE 802.11 may be changed.

In some alternate embodiments, a new-key bit of a received unicast packet may be read to determine whether to switch between keys for decrypting the received unicast packet. In these alternate embodiments, both the authenticator102and the supplicant104may set the new-key bit when transmitting a unicast packet that is encrypted with the new key. In these alternate embodiments, rather than changing how the Key ID values are defined, current or conventional key-ID definitions may be used. In these embodiments, the new-key bit may serve as a toggle indicating to the receiver to switch between keys. In these embodiments, communications may be performed in accordance with one of the IEEE 802.11 standards and a reserved bit may be used for the new-key bit. The current definitions of key ID values of 0, 1, 2 and 3 in 802.11 may also be used. In these embodiments, a key ID value of zero may be used for all unicast packets since the new-key bit used to switch between keys and key ID values of 1, 2, and 3 may be used for non-unicast packets.

In some embodiments, if the authenticator102has set the extended key ID field to one in Message1, and if the supplicant104supports the use of an extended key ID, the supplicant104may negotiate to use an extended Key ID space. In these embodiments, the supplicant104may select the key ID to use to receive packets, with the key being negotiated, and may specify the value in the key ID field in Message2. In these embodiments, the supplicant104would not include the key ID Key Data Encapsulation (KDE) in Message2if the authenticator102sets the extended key ID field to zero in Message1.

If the authenticator102does not support use of the extended key ID, it may ignore the key ID KDE. If the supplicant104does not support the extended key ID, which may be signaled by the RSN IE extended key ID field in Message2being set to zero or the KDE not being present, the authenticator102may continue to use zero as the exclusive unicast key ID. Otherwise, the authenticator102may use the key ID for unicast transmissions to the supplicant104using a temporary key (TK) being negotiated by the four-way handshake103. The authenticator102may also allocate a key ID to use to receive unicast transmissions protected by the TK being negotiated and may include this in a Key ID KDE in Message3. The authenticator102may also echo the supplicant104's value in Message3.

If, in Message3, the authenticator102signals that it agrees to support to an extended key ID by the presence of the Key ID KDE, the supplicant104may check that the proposed key ID of authenticator102is the value the supplicant104proposed in Message2. If not, the four-way handshake103may fail. If, in Message3, the authenticator102signals that it does not support an extended key ID by the presence of the Key ID KDE, the supplicant104may use the proposed key ID in unicast packets that the supplicant104protects, with the TK being negotiated. The supplicant104may reflect the KDE back to the authenticator102in Message4. In these embodiments, the authenticator102may check that Message4included the KDE that it sent in Message3; otherwise the four-way handshake103may fail.

In these embodiments, in response to receipt of a valid Message2, the authenticator102may install the new key for reception with the selected key ID and may then send Message3indicating the new key ID in the key ID KDE. On receipt of a valid Message3, the supplicant104may install the new key for receiving using the key ID received in Message3and may send Message4. The authenticator102may then start queuing packets (e.g., MPDUs) using the new key.

The supplicant104may continue to support receipt of the packets using the old key for a predetermined period of time after transmitting Message4. On receipt of Message4, the authenticator102may start queuing packets using the new key and may continue to support receipt of packets using the old key for a predetermined period of time. In some embodiments, the predetermined period of time may be approximately 60 seconds.

In some alternate embodiments, after the fourth EAP message, both the supplicant104and the authenticator102may start a switchover timer that has a time-delay (e.g., on the order of ten seconds) that is larger than the maximum delay of both devices. During this time period, both supplicant104and the authenticator102may continue using the old key. After the time-delay of the switchover timer, both the supplicant104and the authenticator102may transmit using the new key and may continue to use both the old key and the new key for reception for at least a predetermined period of time.

In some embodiments, the wireless device300may be configured to receive orthogonal frequency division multiplexed (OFDM) communication signals over a multicarrier communication channel. The OFDM signals may comprise a plurality of orthogonal subcarriers. In some of these multicarrier embodiments, the wireless device300may be a wireless local area network (WLAN) communication station such as a wireless access point (AP), base station or a mobile station including a Wireless Fidelity (WiFi) device. In some embodiments, wireless device300may communicate wirelessly within the 2.4 GHz frequency band, the 5 GHz frequency band or the 60 GHz frequency band. In some broadband multicarrier embodiments, the wireless device300may be part of a broadband wireless access (BWA) network communication station, such as a Worldwide Interoperability for Microwave Access (WiMAX) communication station. In some other broadband multicarrier embodiments, the wireless device300may be a 3rd Generation Partnership Project (3GPP) Universal Terrestrial Radio Access Network (UTRAN) Long-Term-Evolution (LTE) communication station. In these broadband multicarrier embodiments, the wireless device300may be configured to communicate in accordance with an orthogonal frequency division multiple access (OFDMA) technique.

In some embodiments, the wireless device300may be configured to communicate in accordance with specific communication standards, such as the Institute of Electrical and Electronics Engineers (IEEE) standards, including IEEE 802.11-2007 and/or 802.11(n) standards and/or proposed specifications for WLANs, although the scope of the embodiments is not limited in this respect as the wireless device300may also be suitable to transmit and/or receive communications in accordance with other techniques and standards. In some embodiments, the wireless device300may be configured to communicate in accordance with the IEEE 802.16-2004, the IEEE 802.16(e) and/or IEEE 802.16(m) standards for wireless metropolitan area networks (WMANs), including variations and evolutions thereof, although the scope of the embodiments is not limited in this respect as the wireless device300may also be suitable to transmit and/or receive communications in accordance with other techniques and standards. In some embodiments, the wireless device300may be configured to communicate accordance with the Universal Terrestrial Radio Access Network (UTRAN) LTE communication standards. For more information with respect to the IEEE 802.11 and IEEE 802.16 standards, please refer to “IEEE Standards for Information Technology—Telecommunications and Information Exchange between Systems”—Local Area Networks—Specific Requirements—Part 11 “Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY), ISO/IEC 8802-11: 1999”, and Metropolitan Area Networks—Specific Requirements—Part 16: “Air Interface for Fixed Broadband Wireless Access Systems,” May 2005 and related amendments/versions. For more information with respect to UTRAN LTE standards, see the 3rd Generation Partnership Project (3GPP) standards for UTRAN-LTE, release 8, March 2008, including variations and evolutions thereof.

In some other embodiments, the wireless device300may be configured to communicate signals that were transmitted using one or more other modulation techniques such as spread spectrum modulation (e.g., direct sequence code division multiple access (DS-CDMA) and/or frequency hopping code division multiple access (FH-CDMA)), time-division multiplexing (TDM) modulation, and/or frequency-division multiplexing (FDM) modulation, although the scope of the embodiments is not limited in this respect.

In some embodiments, the wireless device300may use two or more antennas301for communicating. The antennas301may comprise directional or omnidirectional antennas, including, for example, dipole antennas, monopole antennas, patch antennas, loop antennas, microstrip antennas or other types of antennas suitable for transmission of RF signals. In some embodiments, instead of two or more antennas301, a single antenna with multiple apertures may be used. In these embodiments, each aperture may be considered a separate antenna. In some MIMO embodiments, antennas301may be effectively separated to take advantage of spatial diversity and the different channel characteristics that may result between the communication stations.

FIG. 4is a procedure for receiving packets during rekeying in accordance with some embodiments. Procedure400may be performed by a wireless device, such as wireless device300(FIG. 3), during rekeying operations. In some embodiments, procedure400may be performed by a supplicant104(FIG. 1), for example, during a video-streaming session. In these embodiments, the supplicant104may receive unicast packets that comprise streamed video. The unicast packets may be encrypted with a first key. The supplicant104may receive a rekeying initiation message201(FIG. 2) to initiate rekeying operations and may install a second key for reception prior to transmission of a rekeying confirmation message204(FIG. 2) to the authenticator102(FIG. 1).

In some embodiments, in operation402the supplicant104may read a key ID field in a received unicast packet to determine whether to use the new key or the old key stored in the unicast key ID space for decrypting the received unicast packet. Alternatively, in operation402the supplicant104may read the new-key bit of the received unicast packet to determine whether to switch between either the new key or the old key stored in the unicast key ID space for decrypting the received unicast packet.

In some embodiments, in operation404the supplicant104may read the MAC address of the received packet to determine whether the received packet is either a unicast packet or a non-unicast packet. When the packet is a non-unicast packet, operation410may be performed. When the packet is a unicast packet, operation408may be performed.

In operation408, the supplicant104may index the unicast key ID space based on the key ID field to identify one of the unicast keys. In operation410, the supplicant104may index the non-unicast key ID space based on the key ID field to identify one of the non-unicast keys. In operation412, the packet may be decrypted with the key determined in either operation408or410.