HK1151644B - Method and system for secure block acknowledgement with protected mac sequence number - Google Patents
Method and system for secure block acknowledgement with protected mac sequence number Download PDFInfo
- Publication number
- HK1151644B HK1151644B HK11105635.7A HK11105635A HK1151644B HK 1151644 B HK1151644 B HK 1151644B HK 11105635 A HK11105635 A HK 11105635A HK 1151644 B HK1151644 B HK 1151644B
- Authority
- HK
- Hong Kong
- Prior art keywords
- value
- data unit
- sequence number
- received
- field
- Prior art date
Links
Description
Cross Reference to Related Applications
This application cites and claims priority to U.S. provisional patent application 61/037,222, filed on 2008, month 3, and day 17, and is incorporated herein in its entirety.
Technical Field
The present invention relates to communications networks, and more particularly, to a method and system for secure Block acknowledgement (Block ACK) with protected MAC sequence numbers.
Background
IEEE802.11 defines a communication architecture that enables computing devices to communicate over a Wireless Local Area Network (WLAN). One building block of a WLAN is the Basic Service Set (BSS). A BSS includes a plurality of computing devices or Stations (STAs) that can communicate wirelessly over one or more RF channels within the RF coverage area. The extent of the RF coverage area is determined by the distance from the source station to the destination station over which the data is transmitted over the RF channel.
IEEE802.11 includes a variety of security measures such as Wired Equivalent Privacy (WEP), Temporal Key Integrity Protocol (TKIP), counter mode and cipher blockchain information authentication code (CBC _ MAC) protocol (CCMP), IEEE 802.1X, and robust secure network connection (RSNA) algorithms. The various security measures can ensure the communication security between the stations. A typical method of secure communication is to encrypt the communication data between the source workstation and the destination workstation to prevent others from stealing unencrypted (also known as clear text) data. In the specification of the Medium Access Control (MAC) protocol layer of IEEE802.11, data is also referred to as medium access control service data unit (MSDU) data. The data may be transmitted in a frame body (or payload) field of a Protocol Data Unit (PDU), also referred to as a data frame. In the specification of the MAC protocol layer of IEEE802.11, a frame is also called a MAC Protocol Data Unit (MPDU). Each data frame also includes a Sequence Number (SN) field.
A typical secure communication method involves computing a Message Integrity Code (MIC). The MIC may be calculated from MSDU plaintext data, an MSDU Source Address (SA) field, an MSDU Destination Address (DA) field, and an MSDU priority field. The MIC may also optionally be computed from MPDU plaintext data and an MSDU header that includes an address field, a priority field, and other components. There is also a reserved field in the MIC computation. The MIC is appended to the plaintext data to form an extended data field. The extended data field also includes a padding field. The extended data field may be encrypted to produce an MPDU frame body field. The data MPDU with the encrypted frame body field may be transmitted by the source station to the destination station in a secure communication link. The data transferred in this manner is "protected data". The destination station may send an Acknowledgement (ACK) to the source station to determine that the MPDU was successfully received. The ACK is also referred to as a control frame.
IEEE802.11 supports Block acknowledgement (Block ACK, abbreviated BA) capability. The block acknowledgement capability may enable a source station to transmit a plurality of sequentially numbered frames during a communication session and simultaneously receive a single block acknowledgement from a destination station indicating that any number of frames have been successfully received from a block of sequentially numbered frames. The block acknowledgement capability is established between the source station and the destination station by frame exchange (also referred to as management frames). For example, in a typical exchange management frame procedure, a source station transmits an ADDBA request management frame to a destination station. The destination station transmits an ACK frame to the source station to acknowledge receipt of the ADDBA request frame. The destination station then transmits an ADDBA response frame to the source station. And the source station transmits an ACK frame to the destination station to acknowledge receipt of the ADDBA response frame.
The exchange of management frames between the source and destination stations identifies data frames that will be the subject of block acknowledgements based on (SA, DA, TID) tuples, where TID refers to the communication flow identification code. Each transmitted data frame as a block acknowledgement body has a TID value within its TID field. The TID value may be determined during the exchange of management frames.
In a communication session identified by the (SA, DA, TID) tuple, both the source and destination stations will maintain state information related to the communication. The status information may be represented as a scorecard (scorecard). The source station (TX) scorecard includes a TX scorecard Left Edge (LE) pointer, a TX scorecard Right Edge (RE) pointer, and a TX scorecard size parameter. Firstly, establishing a current window:
TX(size)=TX(RE)-TX(LEinit)+1
wherein TX (RE) refers to TX scorecard RE pointer value, TX (LE)init) Refers to the original TX scorecard LE pointer value, TX (size) refers to the TX scorecard size parameter value. Tx (size) denotes the size of the transmission window, typically determined by the frame, which corresponds to the maximum number of frames that the source station transmits when no ACK is received. TX (LE)init) The value represents the SN value of the smallest number in the data frames transmitted within the transmission window. When the source station receives an acknowledgement for a previously transmitted frame within the transmission window, the TX scorecard LE pointer will reflect the current LE pointer value TX (LE)init) Which represents the SN value of the smallest number in the transmission window when no ACK is received. At any given time, the source station may transmit a frame with an SN value within the following range:
TX(LEcur)≤SN<TX(LEcur)+TX(size)
wherein:
TX(RE)=TX(LEcur)+TX(size)-1
the source station may also receive an ACK frame acknowledging receipt of the frame sent within the transmission window. The destination station (RX) scorecard includes an RX scorecard LE pointer, an RX scorecard RE pointer, an RX buffer window LE pointer, an RX buffer window RE pointer, and an RX window size parameter.
The received frames are initially stored in an RX buffer. At the destination station, the MAC layer protocol entity will extract the payload field portion from the received frame, which is then transmitted to a higher layer protocol entity (e.g., a network layer protocol entity). The MAC layer protocol entity will decrypt the payload field portion before passing the payload to the higher layer protocol entity. RX buffer Window LE pointer value minus 1, i.e. RXbuf(LE) -1, representing the maximum SN value of the received frame for which the payload portion has been transferred to the higher layer protocol entity. Based on RXbuf(LE) value, RX buffer Window RE pointer value, i.e. RXbuf(RE), which can be defined as:
RXbuf(RE)=RXbuf(LE)+RX(size)-1
where RX (size) refers to the RX window size parameter value. Rx (size) denotes the receive window size, measured in frames, which corresponds to the maximum number of frames that the destination station can store in the receive buffer. The destination station may normally receive frames having SN values within the following ranges at any time:
RXbuf(LE)≤SN<RXbuf(RE)
SN < RX received from Source stationbufThe (LE) frames will be dropped at the destination station.
The destination station will adjust RX according to the control frame received from the source stationbuf(LE). For example, the destination station may establish an initial RX based on control frames received from the source stationbuf(LEinit) The value is obtained. For example, a source station may transmit a Block Acknowledgement Request (BAR) control frame to a destination station. The BAR frame includes a Start Sequence Number (SSN) value. The destination station will use the SSN value in the received BAR control frame to establish RXbuf(LEinit) The value:
RXbuf(LEinit)=SSN
an initial RX scorecard LE pointer value RX may also be established based on the received SSN valuesc(LEinit):
RXsc(LEinit)=SSN
Normally, when the received frame comprises consecutive blocks of the sequentially numbered frame, the MAC layer will pass the payload part of the received frame to the higher layer protocol entity. However, if there is a previously buffered frame having a relationship to the (SA, DA, TID) communication session when the BAR frame with SN < SSN is received, the payload portion of the previously buffered frame is delivered to the higher layer protocol entity even if there is a gap in sequence number between the previously buffered frames. This will result in the payload portion of some or all previously buffered frames being discarded in the higher layer protocol entity.
The destination station will respond to having received the BAR control frame by transmitting a Block Acknowledgement (BA) control frame to the source station. The BA control frame includes a bitmap field. The bitmap field will indicate whether any of the data frames transmitted from the source station with a sequence number value SN ≧ SSN have been successfully received by the destination station. For example, the first position of the bitmap field corresponds to a frame with a sequence number SN ═ SSN. A bit value of 0 indicates that the frame with the corresponding SN value was not received by the destination station. For example, successful reception of a frame with a given SN value is indicated by a bit value of 1 for the corresponding bit position in the bitmap field.
The destination station can also adjust RX in response to receiving a data frame from the source stationbuf(LE) value. For example, when the destination station receives the SNrec>RXbuf(LE) data frame, updated RX buffer Window RE pointer value RXupd buf(RE) will be:
RXupd buf(RE)=SNrec
based on updated RXupd buf(RE) value, updated RX buffer Window LE pointer value RXbuf upd(LE) will be determined as:
RXupd buf(LE)=RXupd buf(RE)-RX(size)+1
if there is any SN < RXupd buf(LE) currently buffered data frames whose payload portions are to be transmitted to the higher layer protocol entity even if there is a gap in sequence numbers in these currently stored frames, which will result in some or all of the payload portions of these currently buffered frames being discarded in the higher layer protocol entity.
The destination station may send a BA control frame to the source station in response to either an explicit request or an implicit request from the source station. An example of an explicit request is a BAR control frame. An example of an implicit request is a data frame that includes an indication that the source station requests a BA from the destination station. The destination station may report in the BA control frame that it has succeededSome data frames are received and indicate that other data frames have not been received. And for implicit BA request responses, RX is used if the lowest SN numbered frame in the bitmap field in the BA frame is not successfully receivedbufThe value of (LE) will not change. For example, the bit value of the first bit in the bitmap field of the BA frame will indicate whether the lowest SN numbered frame has been successfully received. The sequence number of this lowest SN numbered frame will be indicated in the SSN field in the transmitted BA frame. Regardless of whether the destination station transmits the BA control frame in response to an explicit request or an implicit request sent by the source station, the source station receiving the BA control frame will utilize the value of the SSN field and the value of the bitmap field to adjust the one or more TX scorecard pointer values.
For destination stations using a sustainable RX scorecard maintenance scheme, RX scorecard information will be maintained after transmission of a BA frame. Therefore, each subsequent BA frame transmitted for a given receive window reflects the history of successfully received data frames in that receive window. As a result, RX is the destination station that is maintained using a sustainable RX scorecardsc(LE)=RXbuf(LE)。
For destination stations using a dynamic RX scorecard maintenance scheme, the RX scorecard information will not be maintained after transmission of a BA frame. In this regard, if after receipt of a data frame has been acknowledged by transmission as a BA frame, the destination station will "forget" that the data frame has been successfully received. RX for destination stations maintained using dynamic RX scorecardscThe (LE) scorecard value is updated for each currently received data frame:
RXsc(LE)=SNrec-RX(size)+1
wherein SN isrecIndicating the sequence number of the currently received data frame.
In current IEEE802.11 security methods, the sequence number field in the transmitted data frame is unprotected. In addition, transmitted control frames, such as BAR control frames and BA control frames, are also unprotected.
Further limitations and disadvantages of conventional and traditional approaches will become apparent to one of skill in the art, through comparison of such systems with some aspects of the present invention as set forth in the remainder of the present application with reference to the drawings.
Disclosure of Invention
A method and/or system is provided for a secure Block acknowledgement (Block ACK) with a protected MAC sequence number, substantially as shown in and/or described in connection with at least one of the figures, as set forth more completely in the claims.
Various advantages, aspects and novel features of the invention, as well as details of an illustrated embodiment thereof, will be more fully described with reference to the following description and drawings.
Drawings
FIG. 1 is a schematic diagram of a system for denial of service attacks for embodiments of the present invention.
Fig. 2 is a diagram of a MAC layer protocol data unit for use in an embodiment of the invention.
Fig. 3 is a diagram illustrating a format of a data packet sequence number according to an embodiment of the invention.
Fig. 4 is a diagram of a robust security network performance field, in accordance with an embodiment of the present invention.
Fig. 5 is a schematic diagram of a communication device according to an embodiment of the invention.
Fig. 6 is a flow diagram of method steps for sequence number protection, in accordance with an embodiment of the present invention.
Figure 7 is a flow diagram of method steps for a robust secure network connection for sequence number protection, in accordance with an embodiment of the present invention.
Detailed Description
Some embodiments of the invention may be embodied in methods and systems for secure block acknowledgement with protected MAC sequence numbers. Various embodiments of the present invention include methods and systems employed by a workstation to protect a Sequence Number (SN) field portion of a transmitted Protocol Data Unit (PDU), such as an MPDU. The method and system of the present invention are also used to implement protection of the Start Sequence Number (SSN) information transmitted by control frames, such as Block Acknowledgement Request (BAR) and Block Acknowledgement (BA) frames, in embodiments of the present invention. Other embodiments of the present invention also include methods and systems by which a communication workstation protects SN information in MPDUs and/or controls SSNs in MPDUs by exchanging management frames.
FIG. 1 is a schematic diagram of a system for denial of service attacks for embodiments of the present invention. Referring to fig. 1, a source station (src _ STA)102, a destination station (dest _ STA)104, and a spoofing station (spoofsta) 106 are shown. The src _ STA102 is identified by the Source Address (SA) S _ STA and the dest _ STA is identified by the Destination Address (DA) D _ STA.
In fig. 1, the src _ STA102 and dest _ STA104 participate in a communication session that is associated with a communication Flow identification (TID), Flow _ 1. The value of TID may be determined by src _ STA102 and dest _ STA104 during the exchange of control frames. The communication session between the src _ STA102 and the dest _ STA104 is identified by one tuple (S _ STA, D _ STA, Flow _ 1). The payload portion of the data frame transmitted during the communication session (S _ STA, D _ STA, Flow _1) may be protected using various security methods. However, the spoofsta 106 may monitor the communication session (S _ STA, D _ STA, Flow _1) and may determine the SA of the src _ STA102, the DA of the dest _ STA104, the TID of the communication session (S _ STA, D _ STA, Flow _1), and the SN of the data frame transmitted in the communication session (S _ STA, D _ STA, Flow _ 1). Although the spoofsta 106 cannot decrypt the payload portion of the data frame transmitted during the communication session (S _ STA, D _ STA, Flow _1), the spoofsta 106 may send a false Block Acknowledgement Request (BAR) control frame 112 to the dest _ STA 104. The BAR control frame 112 includes the following values: SA is S _ STA, DA is D _ STA, TID is Flow _1, and SSN is 2824.
Based on the false BAR control frame 112, the dest _ STA104 may adjust one or more RX scorecard values. For example, the dest _ STA104 may adjust the RX scorecard Left Edge (LE) pointer value and/or the RX buffer window LE pointer value based on the SSN value included in the spurious BAR control frame 112. Based on the adjusted RX scorecard LE pointer value and/or RX buffer window LE pointer value, the dest _ STA104 may reject data frames 114 subsequently transmitted by the src _ STA102 that include SN 1251.
As can be seen from the embodiment of fig. 1, even if the spoofsta 106 cannot detect plaintext data in the data frames transmitted in the communication session (S _ STA, D _ STA, Flow _1), the spoofsta 106 can interrupt the communication session (S _ STA, D _ STA, Flow _1) between the src _ STA102 and the dest _ STA104 by causing the dest _ STA104 to discard the data frames transmitted by the src _ STA 102. The behavior illustrated by the spoofsta 106 in fig. 1 is also referred to as a denial of service (DoS) attack.
Alternatively, the spoofsta 106 may complete a successful DoS attack by transmitting a dummy data frame that includes the following values: SA-S _ STA, DA-D _ STA, TID-Flow _1, and SSN-2824. Once the dest _ STA104 receives the dummy data frame, the dest _ STA104 will adjust the RX buffer window RE pointer value and/or the RX scorecard RE pointer value. In turn, dest _ STA104 will adjust the RX buffer window LE pointer value and/or the RX scorecard LE pointer value. It is assumed that the dest STA104 will discard the data frame 114 transmitted by the src STA102 if the receive window size value is 64 frames.
Looking at the DoS attack from another aspect, the spoofsta 106 may transmit a dummy data frame that includes SN 1279. In this example, the MAC layer protocol entity in the dest _ STA104 will not drop the transmitted data frame 114. However, a corresponding adjustment of the RX scorecard value and/or the RX buffer value, which is performed after receiving the dummy data frame, will result in the payload portion of the received data frame 114 being delivered to the higher layer protocol entity in an incorrect order with respect to other payload portions delivered to the higher layer protocol entity. During decryption of the payload portion of the received data frame 114, the security method used in the communication session (S _ STA, D _ STA, Flow _1) will detect an error. For example, in decrypting the payload portion of the received data frame 114, a packet sequence number (PN) value will be calculated. Using various security methods, the dest _ STA104 may determine that storing the received data frame 114 in the receive buffer of the dest _ STA104 may result in the payload portion of the data frame 114 being delivered to higher layer protocol entities in an incorrect order relative to other buffered payload portions. Out-of-order delivery of the payload portion to the higher layer protocol entity will result in error handling of the received data by the higher layer protocol entity. And this error handling may result in, for example, data loss.
Fig. 2 is a diagram of a MAC layer protocol data unit for use in an embodiment of the invention. As can be seen in fig. 2, MPDU 202 is shown. The MPDU 202 is generated in accordance with the IEEE802.11 standard, a CCMP security method, and/or a Wi-Fi protected access (WPA) security method. The MPDU 202 includes a MAC header field 204, a CCMP header field 206, a payload data field 208, a MIC field 210, and a Frame Check Sequence (FCS) field 212. In the general MPDU format specified in the IEEE802.11 standard, the combination of the payload data field 208 and the MIC field 210 corresponds to a frame body field. Example MAC header fields 204 include SA, DA, SN, TID, and other fields specified in accordance with the IEEE802.11 standard. The exemplary CCMP header field 206 includes a packet sequence number (PN) field as specified in accordance with the IEEE802.11 standard. Payload data field 208 corresponds to plaintext data, which corresponds to a MAC layer service data unit (MSDU). MIC field 210 corresponds to a message integrity check field. The clear text versions of the payload data field 208 and the MIC field 210 will be encrypted according to the CCMP security method. Encrypted versions of the payload data field 208 and the MIC field 210 will be transmitted over the MPDU 202.
Encrypted versions of the payload data field 208 and the MIC field 210 will be generated from the PN value. The payload data field 208 in the transmitted MPDU 202 is protected by existing security methods, but the SN section is not protected. In various embodiments of the present invention, the SN will be protected by using the SN value to generate the PN value. As a result, encrypted versions of the payload data field 208 and the MIC field 210 will be generated based at least on the SN value. In this way, the SN field is protected.
Fig. 3 is a diagram illustrating a format of a data packet sequence number according to an embodiment of the invention. Referring to fig. 3, a packet sequence number (PN) format 302 is shown that includes a TID field 304, a middle bit field 306, and a MACSN field 308. TID field 304 corresponds to the TID field in MAC header field 204. In a preferred embodiment of the present invention, TID field 304 comprises 4 bits. The MAC SN field 308 corresponds to the SN field in the MAC header field 204. In a preferred embodiment of the present invention, the MAC SN field 308 includes 12 bits.
In a preferred embodiment of the present invention, the middle bit field 306 comprises 32 bits. The value of the intermediate bit field 306 may be determined from the MAC SN field 308. In this regard, the intermediate bit field 306 may be an extension of the MAC SN field 308. For example, the value of the middle bit field 306 is incremented by 1 each time the value of the MAC SN field 308 exceeds 4095. The value of TID field 304 may be determined based on the exchange of management frames when negotiating block acknowledgement capabilities between the source and destination stations.
The preferred embodiment of the present invention can generate 244 unique PN values. In addition to the PN value, the encrypted versions of the payload data field 208 and the MIC field 210 may be determined based on a temporal key (key) value. In a preferred embodiment of the invention, the key comprises 128 bits. A new key value is generated when the set of unique PN values is used in a communication session, such as when a subsequent PN value is equal to a previous PN value in a communication session. The new key value is then used at the beginning of the repetition of the sequence of PN values.
In various embodiments of the present invention, PN format 302 is used in CCMP header field 206. The encrypted versions of the payload data field 208 and the MIC field 210 will be calculated according to: a secret key; a frame body (including payload data field 208 and MIC field 210); random number (nonce); auxiliary Authentication Data (AAD). In a preferred embodiment of the present invention, the AAD is generated based on fields contained in the MAC header field. In embodiments of the present invention, the generation of the AAD is unchanged from existing security methods. The random number will be generated based on the value of the PN 302, DA field, and the priority field value (from the MAC header field 204).
The installation method may be implemented between the source station and the destination station based on an exchange of management frames, which establishes an association between the source station and the destination station. Exemplary management frames for a connection include, for example, a beacon frame, a connection request frame, and a connection response frame. The security method may be used in conjunction with a robust secure network connection (RSNA). The management frame implementing RSNA includes an RSN Information Element (IE). The RSN IE will identify the security methods that enable secure communication between the source and destination stations. The RSN IE includes an RSN capability field.
In an embodiment of the invention, SN protection may be implemented based on the modified RSN capability field during the exchange of management frames. Fig. 4 is a diagram of a robust security network performance field, in accordance with an embodiment of the present invention. Referring to fig. 4, RSN capabilities field 402 is shown, which includes a pre-authentication field (pre _ auth)404, an unpaired field 406, a pairwise temporal key secure join (PTKSA) replay counter field 408, a group temporal key secure join (GTKSA) replay counter field 410, reserved fields 412, 416, 420, a peer key enabled field (peerney enabled field)414, and a protected SN field 418.
The pre-authentication field 404, the unpaired field 406, the PTKSA replay counter field 408, the GTKSA replay counter field 410, and the peer key enable field 414 are all described in the IEEE802.11 standard. The reserved fields 412, 416, 420 are all set to predetermined values.
In an embodiment of the present invention, the protected SN field 418 may indicate whether the sending STA is capable of SN protection using a security method. In a preferred embodiment of the present invention, the protected SN field 418 includes only one bit. The value of the protected SN field in the transmitted management frame is "1", indicating that the transmitting STA can perform SN protection using a security method. The value of the protected SN field in the transmitted management frame is "0", indicating that the transmitting STA cannot perform SN protection using a security method. According to an embodiment of the present invention, in a management frame exchange procedure for RSNA, if values of protected SN fields in management frames transmitted by both a source station and a destination station are both "1", the source station and the destination station may establish RSNA using a security method to protect SN.
Although fig. 4 illustrates a modified RSN capability field 402 for use in an RSN IE, embodiments of the invention are not limited in this regard. For example, in other embodiments of the present invention, the security method for SN protection may also be implemented using different fields in the RSN IE, or using a new field in the RSN IE, or using fields in different elements.
Fig. 5 is a schematic diagram of a communication device according to an embodiment of the invention. Referring to fig. 5, a transceiver system 500, a receive antenna 522, and a transmit antenna 532 are shown. The transceiver system 500 may be an example of the src _ STA102 and/or the dest _ STA 104. The transceiver system 500 includes at least one receiver 502, a transmitter 504, a processor 506, and a memory 508. Processor 506 also includes memory 518. Although a transceiver is shown in fig. 5, its receiving and transmitting functions may be implemented separately. In embodiments of the present invention, transceiver system 500 may include multiple transmit antennas and/or multiple receive antennas. In other embodiments, only a single antenna may be included and coupled to the receiver 502 and the transmitter 504 through a duplexer.
The receiver 502 may comprise suitable logic, circuitry, interfaces and/or code that may be operable to perform receiver functions including physical layer PHY functions for signal reception. The PHY layer functions include, but are not limited to, amplifying a received RF signal, generating a frequency carrier signal corresponding to a selected RF channel (e.g., uplink or downlink channel), down-converting the amplified RF signal with the generated frequency carrier signal, demodulating data in the data symbols according to a selected demodulation type, and detecting data contained in the demodulated signal. The RF signal may be received through a receive antenna 522. The data may be communicated to processor 506.
The transmitter 504 may comprise suitable logic, circuitry, interfaces and/or code that may enable transmitter functions, including PHY layer functions for signal transmission. These PHY layer functions include, without limitation, modulating received data according to a selected modulation type to produce data symbols, generating a frequency carrier signal corresponding to a selected RF channel (e.g., uplink or downlink channel), up-converting the data symbols with the generated frequency carrier signal, and generating and amplifying the RF signal. Data is received from processor 506. The RF signal is transmitted through the transmission antenna 532.
The memory 508 may comprise suitable logic, circuitry, interfaces and/or code that may enable storage and/or retrieval of data and/or code. The memory 508 may use a variety of storage medium technologies such as volatile memory, e.g., Random Access Memory (RAM), and/or non-volatile memory, e.g., electrically erasable read-only memory (EEPROM). The memory 508 described herein may store codes for generating PN values, temporary keys, and/or codes for data encryption for SN protection. Memory 508 may also be used to store RX scorecard information and/or RX buffer information and/or TX scorecard information. Memory 508 may be used to store other state information.
The memory 518 may comprise suitable logic, circuitry, interfaces and/or code that may enable the storage and/or retrieval of data and/or code. The memory 518 may employ a variety of storage medium technologies such as volatile memory, e.g., Random Access Memory (RAM), and/or non-volatile memory, e.g., electrically erasable read-only memory (EEPROM). The memory 518 described herein may store codes for generating PN values, temporary keys, and/or data encryption for SN protection. Memory 518 may also be used to store RX scorecard information and/or RX buffer information and/or TX scorecard information. Memory 518 may be used to store other state information.
The processor 506 may store code and/or data stored in the memories 508 and/or 518. The processor 506 may retrieve the code and/or data from the memories 508 and/or 518. The processor 506 may use the memory 518 to store internal data and/or code. A typical internal memory is a cache memory. The processor 506 may use the memory 508 to store external data and/or code. Memories 508 and 518 described herein may be used interchangeably by processor 506.
In operation, the processor 506 in the source station may generate management frames, such as beacon frames, for the RSNA. Processor 506 may generate a beacon frame including the RSN IE. The RSN IE includes an RSN capabilities field 402. The processor 506 may indicate that the source station may utilize a security method for SN protection by setting a value in the protected SN field 418. The beacon frame is transmitted to transmitter 504. The transmitter 504 may generate a physical layer protocol data unit (PPDU) based on the beacon frame. The PPDU will be transmitted by transmitter 504 to the destination station via transmit antenna 532.
Receiver 502 will receive the transmitted PPDU via receive antenna 522. The received PPDU includes a physical layer service data unit (PSDU) that contains MPDUs. Receiver 502 may send the MPDU to processor 506. The processor 506 may determine that the MPDU contains a management frame, such as a connection request frame, that is transmitted by the destination station. The processor 506 may determine that the received management frame contains the RSNIE. The RSN IE includes an RSN capability field. The RSN capabilities field includes a protected SN field 418 that indicates that the destination station uses a security method to protect the SN. Processor 506 at the source station may generate and receive subsequent management frames to establish the RSNA with the destination station.
The operation of the destination station processor 506 is substantially similar to that described above. For example, the destination station processor 506 may determine that a beacon frame was received from the source station. For example, the processor 506 may generate a connect frame indicating that the destination station uses a security procedure to protect the SN.
According to the above, once RSNA is established for SN protection, the source and destination stations may negotiate a block acknowledgement protocol based on management frame exchange. A data flow (flow) subject to the block acknowledgement protocol can be identified based on the tuple (SA, DA, TID). Processor 506 of the destination station receives one or more data frames associated with the data stream. For each received data frame, processor 506 decrypts the encrypted body of the received data frame based on the encrypted body, the temporary key, the generated AAD, and the generated random number. The processor 506 of the destination station may generate the random number based on the SN value in the received data frame. In an embodiment of the invention, the integrity check of the MIC value by the destination station will fail if the received data frame includes a false SN value. In a preferred embodiment of the present invention, processor 506 will calculate an integrity check value based on at least a portion of the decrypted received data frame. The calculated integrity check value will be compared to the MIC field 210 in the received data frame. Based on the comparison, the processor 506 may determine whether the integrity check succeeded or failed. In the event of a failure of the MIC integrity check, the processor 506 will discard the received data frame. However, when processor 506 determines that the MIC integrity check fails, processor 506 may not adjust the RX scorecard value and/or the RX buffer value and/or other state information stored in the destination station for the dropped data frame. If the received data frame does not include a false SN value, the MIC integrity check will not fail. In the event that the MIC integrity check does not fail, the destination station will accept the clear text version of the payload portion in the data frame. The clear text version of the payload data 208 will be stored in the receive buffer waiting to be subsequently passed to the higher layer protocol entity. Accordingly, one or more RX scorecards and/or RX buffer values and/or other status information stored in the destination station will be adjusted.
The security methods described herein may also be used in conjunction with WPA security methods. Embodiments of the present invention are also not limited to sequence number protection with block acknowledgements. Other embodiments of the present invention may also be implemented with single frame transmissions and acknowledgements and/or using other non-block ACK communications. The method and system for implementing secure response by serial number protection are very similar to the method and system for performing secure block response by detecting serial number according to the present invention. For example, in the example of a method and system for implementing secure replies with sequence number protection, as described herein above, the destination station will perform a MIC integrity check on the received data frame. Based on the result of the MIC integrity check, when the MIC integrity check result indicates success, the destination station will accept the received data frame and modify the state information, such as the replay counter. Additionally, when the MIC integrity check result indicates a failure, the destination station will discard the received data frame and not modify the state information, such as the replay counter.
In an embodiment of the invention, the destination station may receive the data frame with SN protection in case the data frame is received according to a block acknowledgement protocol between the source station and the destination station, whereas in other embodiments of the invention the destination station may receive the data frame with SN protection when the data frame is received without a block acknowledgement protocol between the source station and the destination station.
Fig. 6 is a flow diagram of method steps for sequence number protection, in accordance with an embodiment of the present invention. Referring to fig. 6, in step 602, a destination station receives a data frame from a source station. According to embodiments of the present invention, the body of the received data frame may be protected using various security methods. In step 604, the destination station will determine the SN value in the received data frame. In step 606, the destination station generates a temporary key, AAD, and a random number to decrypt the protected body of frames. A random number may be generated based on the SN value in step 604. In step 608, the destination station performs an integrity check based on the MIC field in the received data frame. Step 610 will determine if the MIC integrity check was successful. When the MIC integrity check in step 610 succeeds, the plaintext data in the received data frame is buffered in a receive buffer in the destination station in step 612. In step 614, one or more RX scorecard values and/or RX buffer values and/or other status information will be adjusted according to the received data frame. For example, the destination station will update the RX scorecard value and/or the replay counter to indicate that the data frame having the SN value determined in step 604 has been successfully received. When the MIC integrity check in step 610 is unsuccessful, the destination station will discard the received data frame in step 616.
Figure 7 is a flow diagram of method steps for a robust secure network connection for sequence number protection, in accordance with an embodiment of the present invention. Referring to fig. 7, in step 702, a destination station receives a beacon frame from a source station. In a preferred embodiment of the invention, the destination station comprises an Access Point (AP) within a Wireless Local Area Network (WLAN) in a Basic Service Set (BSS). In step 704, the destination station determines whether the beacon frame includes a protected SN field 418, where the protected SN field 418 indicates that the source station transmitting the beacon frame is to use a security method to protect the SN. In the case when the protected SN field 418 in the received beacon frame indicates that the source station protected the SN using a secure method, the destination station sends a management frame (such as a connection request frame) to the source station in step 706. The connection request frame includes a protected SN field 418 indicating that the destination station protects the SN using a secure method. In step 708, the source and destination stations participate in a subsequent management frame exchange to establish RSNA, which protects the SN using a secure method.
In the case where the protected SN field 418 in the received beacon frame indicates that the source station is not SN protected using a security method, the destination station will transmit a management frame to the source station in step 710. The transmitted management frame contains a protected SN field 418 indicating that the destination station does not use a security method for SN protection. In step 712, the source and destination stations participate in a subsequent management frame exchange to establish an RSNA that does not use a secure method to protect the SN.
Another embodiment of the present invention provides a machine and/or computer readable storage and/or medium having stored thereon a machine code and/or computer program having at least one code section executable by a machine and/or computer. Causing the machine and/or computer to perform the method steps described above for the protected MAC sequence number and for the secure block reply with the protected MAC sequence number.
Accordingly, the present invention may be realized in hardware, software, or a combination of hardware and software. The present invention can be realized in a centralized fashion in at least one computer system, or in a distributed fashion where different elements are spread across several interconnected computer systems. Any kind of computer system or other apparatus adapted for carrying out the methods described herein is suited. A typical combination of hardware and software could be a general purpose computer system with a computer program that, when being loaded and executed, controls the computer system such that it carries out the methods described herein. The method is implemented in a computer system using a processor and a memory unit.
The present invention can also be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which when loaded in a computer system is able to carry out these methods. Computer programs in this context mean: any expression, in any programming language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following a) conversion to another language, code or notation; b) reproduced in different material forms to realize specific functions.
While the invention has been described with reference to several embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted without departing from the scope of the invention. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the invention without departing from its scope. Therefore, it is intended that the invention not be limited to the particular embodiment disclosed, but that the invention will include all embodiments falling within the scope of the appended claims.
Claims (20)
1. A method for transmitting information in a communication network, the method comprising:
performing, using at least one processor, functions comprising:
receiving a medium access control protocol data unit from a sequence comprising a plurality of medium access control protocol data units;
determining a sequence number value of the received protocol data unit, the sequence number value representing a position of the received medium access control protocol data unit in the sequence;
generating a random number based on the determined sequence number value;
decrypting at least a portion of the received medium access control protocol data unit based on the random number;
generating adjusted state information for receipt of a media access control protocol data unit based on the decrypting;
storing the adjusted state information in a memory.
2. A method of transmitting information in a communication network according to claim 1, wherein the method comprises: the random number is generated based on a packet sequence number value, a destination address value, and a priority field value, the packet sequence number value including the sequence number value, a median value, and a traffic flow identification code value.
3. A method of transmitting information in a communication network according to claim 2, characterised in that the method comprises: decrypting a service data unit portion of the received medium access control protocol data unit based on the generated random number.
4. A method of transmitting information in a communication network according to claim 3, characterised in that the method comprises: an integrity check value is calculated based on the decrypted service data unit portion.
5. The method of claim 4, wherein the method comprises: comparing the calculated integrity check value with a predetermined integrity check value.
6. The method of claim 5, wherein the method comprises: determining the predetermined integrity check value based on the decrypted service data unit portion.
7. The method of claim 6, wherein the method comprises: determining the predetermined integrity check value based on a message integrity check field portion within the decrypted service data unit portion.
8. The method of claim 5, wherein the method comprises: generating the adjusted state information based on the comparison result.
9. The method of claim 8, wherein the method comprises: after generating the adjusted state information, storing data decrypted from the received protocol data unit.
10. The method of claim 8, wherein the adjusted status information comprises one or more of a receiver scorecard value, a receiver buffer value, and a replay counter.
11. A system for transmitting information in a communication network, the system comprising:
one or more circuits configured to receive a medium access control protocol data unit from a sequence comprising a plurality of medium access control protocol data units;
the one or more circuits are configured to determine a sequence number value for the received protocol data unit, the sequence number value indicating a position of the received medium access control protocol data unit in the sequence;
the one or more circuits are to generate a random number based on the determined sequence number value;
the one or more circuits are configured to decrypt at least a portion of the received medium access control protocol data unit based on the random number;
the one or more circuits are configured to generate adjusted state information for receipt of a medium access control protocol data unit based on the decryption;
the one or more circuits are operable to store the adjusted state information in a memory.
12. The system according to claim 11, wherein said at least one circuit generates said random number based on a packet sequence number value, a destination address value, and a priority field value, said packet sequence number value including said sequence number value, a median value, and a traffic flow identifier value.
13. The system according to claim 12, wherein said one or more circuits are operable to decrypt a service data unit portion of said received mac protocol data unit based on said generated random number.
14. The system according to claim 13, wherein said at least one circuit calculates an integrity check value based on said decrypted service data unit portion.
15. The system according to claim 14, wherein said one or more circuits compare said calculated integrity check value to a predetermined integrity check value.
16. The system according to claim 15, wherein said one or more circuits determine said predetermined integrity check value based on said decrypted service data unit portion.
17. The system according to claim 16, wherein said one or more circuits determine said predetermined integrity check value based on a message integrity check field portion within said decrypted service data unit portion.
18. The system according to claim 15, wherein said one or more circuits generate said adjusted state information based on said comparison.
19. The system according to claim 18, wherein said one or more circuits store data decrypted from said received pdu after said adjusted state information is generated.
20. The system for communicating information in a communication network of claim 18, wherein the adjusted status information includes one or more of a receiver scorecard value, a receiver buffer value, a replay counter.
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US3722208P | 2008-03-17 | 2008-03-17 | |
US61/037,222 | 2008-03-17 | ||
PCT/US2009/037350 WO2009117384A2 (en) | 2008-03-17 | 2009-03-17 | Method and system for secure block acknowledgement (block ack) with protected mac sequence number |
Publications (2)
Publication Number | Publication Date |
---|---|
HK1151644A1 HK1151644A1 (en) | 2012-02-03 |
HK1151644B true HK1151644B (en) | 2014-02-21 |
Family
ID=
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8473732B2 (en) | Method and system for secure block acknowledgment (block ACK) with protected MAC sequence number | |
CN103945376B (en) | The wireless device and method that re-cipher key is carried out in the case where reducing packet loss conditions for high throughput wireless communication | |
US9071416B2 (en) | Galois/counter mode encryption in a wireless network | |
US11228908B2 (en) | Data transmission method and related device and system | |
EP2288195B1 (en) | Method and apparatus for operating a base station in a wireless communication system | |
CN104661216B (en) | The method and WTRU of NAS message are transmitted in WTRU | |
KR101378647B1 (en) | Providing apparatus and method capable of protecting privacy mac frame in ieee 802.15.4 networks | |
US9769653B1 (en) | Efficient key establishment for wireless networks | |
JP2013225863A (en) | Method and apparatus to implement security in long term evolution wireless device | |
CN107113287A (en) | Method for performing device-to-device communication between user equipment | |
US7400733B1 (en) | Key refresh at the MAC layer | |
AU2010284792B2 (en) | Method and apparatus for reducing overhead for integrity check of data in wireless communication system | |
CN102026186B (en) | Service network detection system and method | |
US8094634B2 (en) | Sender and/or helper node modifications to enable security features in cooperative wireless communications | |
US10298386B1 (en) | Method and apparatus for secure communications in networks | |
KR100580844B1 (en) | Data Security and Operation Device and Method in Wireless LAN System | |
HK1151644B (en) | Method and system for secure block acknowledgement with protected mac sequence number | |
US20250260970A1 (en) | Method for updating information, and device and chip | |
KR20100026722A (en) | Apparatus and method for reduction of encryption overhead in wireless access system |