METHOD, DEVICES AND SYSTEMS FOR SECURING WIRELESS SYSTEMS AGAINST INSIDER INFORMATION ATTACKS
Patent Information
- Application Number
- DE102024129103
- Authority / Receiving Office
- DE · DE
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-10-09
- Publication Date
- 2025-04-10
Smart Images

Figure 00000000_0000_ABST
Abstract
Description
CROSS REFERENCE TO RELATED APPLICATIONSThe present application claims priority to and benefit of U.S. Patent Application No. 63 / 543,406, filed October 10, 2023, the contents of which are incorporated herein by reference in their entirety.TECHNICAL FIELDThe present disclosure relates generally to wireless systems, and more particularly, to wireless systems that can protect themselves from attacks using insider information, such as the addresses and / or identification values of devices that have already joined the network.BACKGROUNDWireless systems, such as systems compatible with some IEEE 802.11 wireless standards, may be vulnerable to attacks using the media access control (MAC) address of a station device (STA) already associated with a basic service set (BSS) comprising a distributed system (DS) BSS (i.e., a MAC Steeler attack).One type of MAC Steeler attack may override a security context of an associated STA (the "victim" STA). In such an attack, an attacker may disconnect a victim STA from an access point device (AP) using a variety of methods including a management frame protection deauthentication frame (MFP). The attacker may then connect to the AP using the victim STA's MAC address. Such an attack need not require close timing between attacker messages, as a request from a victim STA could be retransmitted from an endpoint (e.g., HTTP response data by TCP transmission). An example of a security context override attack is shown in Figure 35.Referring to FIG. 35, a system 3501 may include an AP 3505 that may control access to a BSS. A STA 3503 may join a network using an exchange of association messages 3509. Such a method may include any suitable associating methods and authentication / security steps, including, but not limited to, passpoint published by the Wi-Fi Alliance, or WPA-3 (including an enterprise mode). Such methods may include steps for simultaneous authentication of Equals (SAE) public key (PK) (SAE-PK).Once associated, a STA 3503 may issue HTTP requests 3511 for servicing by the AP 3505. However, before the HTTP request 3511 can be served, an attacker 3508 owned by the MAC address of the STA 3503 can falsify a deauthentication message 3508-0 addressed to the STA 3503. An attacker 3508 may then search for a connection with the AP 3505 using the misappropriated MAC address and its own login information 3513. The AP 3505 may erroneously override the security context corresponding to the STA 3503 with a new context created and controlled by the attacker 3508, 3505-0. An AP 3505 may then erroneously prepare a response frame to the HTTP request using the overwritten context and send it to the attacker's MAC address (misappropriated), 3505-1. In this way, the attacker can acquire downlink data destined for the STA 3503.Another type of MAC Steeler attack is a fast re-connect attack. A fast re-connect attack may be directed to a DS having more than one AP. Assuming a victim STA is connected to a first AP (AP1), an attacker can connect to a second AP (AP2) using the victim STA's MAC address. The DS may then deliver downlink traffic (destined for the victim STA) to the attacker via AP2, as a DS may be configured to forward traffic to the AP with which the MAC address was last authenticated. An example of a fast reconnection attack is shown in Figure 36.Referring to FIG. 36, a system 3601 may include a DS 3605 having two APs (AP1 3605-0, AP2 3605-1). A STA 3603 may associate with the DS 3605 via AP1 3605-0 with connection and authentication steps 3615. An attacker 3608 may associate with AP2 3605-1 using a forged MAC address 3613 (i.e., the MAC address of STA 3603). In response, AP2 3605-1 may begin to associate with attacker 3608. In the example shown, this may include association and authentication including a four-way handshake 3617. AP2 3605-1 may cache a paired master key (PMK) negotiated with the attacker, 3605-10. AP2 3605-1 may use a PMKID to track the PMK associated with the (corrupted) MAC 3621.The STA 3603 may issue a request 3619 to the DS 3605 via AP1 3605-0. However, due to association by attacker 3621, AP2 3605-1 may load 3605-11 the cached PMK (generated with the attacker's login information). A four-way handshake may be performed 3623 between attacker 3606 and AP2 3605-1 to create encryption keys. Since attacker association is the latest, the DS 3605 may transmit a response 3625 (corresponding to the request 3619) to the attacker 3608 and not to the STA 3603.Any way to prevent or otherwise override such insider information attacks could significantly contribute to the security of wireless systems.SUMMARYA method may include, by operating a first wireless device, receiving wireless messages from a wireless network, determining that a received wireless message is a disconnect message instructing the first wireless device to end communications over the wireless network. The received disconnect message may be determined to be invalid in various ways. In a manner, at least a portion of the received separation message may be decrypted. If a shared secret value is not found, the disconnect message may be determined to be invalid. A shared secret value may be a value previously created during a network join operation by the first wireless device. In another way, a first wireless device may transmit, in response to a disconnect message, a query message addressed to at least one source address of the received disconnect message. If the first wireless device receives more response messages than expected (e.g., if both the valid device and the attacker respond to the challenge), the disconnect message may be determined to be invalid. An invalid disconnect message may be ignored. Corresponding devices and systems are also disclosed.BRIEF DESCRIPTION OF THE FIGURESFIG. 1 is a signaling diagram illustrating a system and corresponding operations according to an embodiment. FIG. 2 is a signaling diagram illustrating a system and corresponding operations according to another embodiment. FIG. 3 is a signaling diagram illustrating a system and corresponding operations according to another embodiment. FIG. 4 is a signaling diagram illustrating a system and corresponding operations according to another embodiment. FIG. 5 is a signaling diagram illustrating a system and corresponding operations according to another embodiment. FIG. 6 is a diagram of a data frame of a notification for a secure session, according to an embodiment. FIG. 7 is a diagram of a data frame of a notification for a secure session according to another embodiment. FIG. 8 is a diagram of a data frame of a secure session request, according to an embodiment. FIG. 9 is a diagram of a data frame of a secure session request according to another embodiment. FIG. 10 is a diagram of a data frame of a secure session response, according to an embodiment. FIG. 11 is a diagram of a data frame of a secure session response according to another embodiment. FIG. 12 is a diagram of a data frame including secure session data, according to an embodiment. FIG. 13 is a diagram of a data frame including a secure session identity information element, according to an embodiment. FIG. 14 is a diagram of a data frame of a secure session update according to an embodiment. FIG. 15 is a diagram of a data frame of a secure session update according to another embodiment. FIG. 16 is a diagram of a data frame of a secure session update acknowledgment (ACK), according to an embodiment. FIG. 17 is a diagram of a data frame of a secure session update ACK according to another embodiment. FIG. 18 is a diagram of a data frame of a secure session request, according to an embodiment. FIG. 19 is a diagram of a data frame of a secure session request according to another embodiment. FIG. 20 is a diagram of a response to a request for secure session data, according to an embodiment. FIG. 21 is a diagram of a response to a request for secure session data according to another embodiment. FIG. 22 is a flow diagram of a method according to an embodiment. FIG. 23 is a flow diagram of a method according to another embodiment. FIG. 24 is a flow diagram of a method according to another embodiment. FIGS. 25-0 and 25-1 show a flow chart of a method according to another embodiment. FIG. 26 is a flow diagram of a method according to another embodiment. FIG. 27 is a flow diagram of a method according to another embodiment. FIG. 28 is a flow diagram of a method according to another embodiment. FIG. 29 is a block diagram of an apparatus according to an embodiment. FIG. 30 is a block diagram of an access point device according to an embodiment. FIG. 31 is a block diagram of a station apparatus according to an embodiment. FIG. 32 is a diagram of an integrated circuit device according to an embodiment. FIG. 33 is a diagram of a vehicle system according to an embodiment. FIG. 34 is a diagram illustrating a system including Internet of Things (IoT) type devices according to an embodiment. Fig. 35 is a signaling diagram showing a first type insider information attack. Fig. 36 is a signaling diagram showing a second type insider information attack.DETAILED DESCRIPTIONAccording to embodiments, a wireless network may be protected from attackers having "insider" information, such as a media access control (MAC) address of the device, as just one example.According to some embodiments, a wireless device may create secure session data with another device when joining a network. Secure session data may include a device identification value (ID) and a shared secret. A shared secret may be a value known to both devices. When the wireless device receives a disconnect message instructing it to end communications on the wireless network, the disconnect message may be further decrypted. If the decrypted message does not include the shared secret, the completion message may be ignored.In some embodiments, a wireless network may be compatible with one or more IEEE 802.11 wireless standards, and a disconnect message may be a deassociation or deauthentication frame. A network join operation that creates a shared secret may be created during an association operation.In some embodiments, a first access device (e.g., an access point device, AP) may transmit its secure session data to a second access device of a same network (e.g., a distributed system, DS). Conversely, the second access device can provide its secure session data to the first access device.In some embodiments, an access device may decrypt the request in response to receiving a request to join a network having a known device ID. If the decrypted request does not include a corresponding shared secret, the request to join again may be ignored. Alternatively, the request to join again may be provided, but messages addressed to the requesting device may be discarded for a timeout period.According to embodiments, when a wireless device receives a disconnection, the wireless device may issue a query message to the supposed source of the completion message. A query message may be a type of message that triggers a response message from a target device. If the wireless device receives two or more response messages, the completion message may be ignored. In some embodiments, a wireless device may check a disconnect message in this manner when a session corresponding to the disconnect message is active.In some embodiments, a wireless network may be compatible with one or more IEEE 802.11 wireless standards, and a query message may include, but is not limited to, a block acknowledge request (BAR), a low power polling message (PS polling), or a null frame.According to embodiments, wireless network operations may provide additional security features for existing protocols (e.g., new information elements, IEs) that allow an access device to verify whether an joining device has a shared secret with the access device. Such a shared secret may have been previously created when the requesting device has previously joined the wireless network. If the joining device does not present the shared secret, the access device may reject the joining device or accept the joining device, but discard any pending messages for the joining device for a predetermined period of time.According to embodiments, devices may create a shared secret upon join a wireless network. Such a shared secret may be used as an additional security layer to defend attacks that use messages to remove a device from a network (e.g., a deassociation or deauthentication message).FIG. 1 is a signaling diagram illustrating operations of a system 100, according to an embodiment. A system 100 may include an access device (e.g., AP) 102, a client device (e.g., STA) 104, and remaining portions of a DS 106. FIG. 1 also shows an attacker 108 owned by a device address (e.g., MAC address) of the STA 104. A system 100 may operate by devices (AP 102, STA 104) transmitting and receiving protocol data units (PDU) according to one or more wireless standards. In some embodiments, a system 100 may be compatible with one or more IEEE 802.11 wireless standards (referred to herein as WLAN). However, alternative embodiments may include any suitable wireless standards that include a join level (e.g., association) that may create an encryption scheme for data frame values over the layer with a device address.Referring now to FIG. 1, operations of a system 100 will be described. A STA 104 may transmit a request to join a wireless network 104- 0, where access to the network may be controlled by the AP 102. Such a request for join 104- 0 may indicate an additional security level (e.g., a secure session (secure session)) and include values associated with such additional security including, but not limited to, a method of generating a shared secret (described in more detail below) and a timeout value.In some embodiments, a request to join 104- 0 may be a WLAN compatible association request. Further, such an association request may be transmitted after detecting a beacon from the AP 102 or after transmitting a probe and receiving a probe response from the AP 102. In some embodiments, a beacon, probe request, or probe response may indicate that the AP 102 is capable of secure session operations. In some embodiments, a request to join may include a device address (e.g., MAC address) and may indicate an action (e.g., generate secure session data) and a timeout value. A timeout value is described in more detail below.In response to a secure session request to join a network 104-0, the AP 102 may generate secure session context data 102-0. Secure session context data may include, but is not limited to, a device address (e.g., MAC address), a shared secret (e.g., secret code), and a timeout period. It should be appreciated that such a record (e.g., tuple) may be generated when any device compatible with a secure session joins the network. Once secure session context data is generated, the AP 102 may transmit a response 102- 1 comprising secure session context data to the STA 102. In some embodiments, such a response may be an association response with a secure session response. In some embodiments, the AP 102 may also transmit secure session data for the STA 102 to other access devices of a system 100.Upon receiving the response 102- 1, the STA 104 may have created the necessary encryption scheme for wireless network communication as well as confirming that the communication may include secure session operations. In some embodiments, a STA 104 may generate a shared secret with data provided by the AP 102. In other embodiments, a shared secret may take any suitable form, including encryption keys obtained when creating the cryptographic scheme for communication over the wireless network. In some embodiments, secret values may include, but are not limited to, a master pair key (PMK) or a transition pair key (PTK) generated during a WLAN association operation.FIG. 1 shows how the STA 104 communicates over the wireless network with a message 110- 0 transmitted to the AP 102, which may be transmitted as forwarded message 110- 1 to other portions of the system 106.FIG. 1 illustrates operations of the system 100 in response to an attacker 108 owning the MAC address of the AP 104 attempting to access data. An attacker 108 may transmit a message 108- 0 indicating that the STA 104 should disconnect from the wireless network. In some embodiments, such a disconnect message may be a WLAN deassociation frame or a deauthentication frame.Upon receiving the completion message 108- 0, the STA 104 may decrypt the message to determine whether it is in possession of the shared secret associated with the AP 102. Because attacker 108 is not in possession of the shared secret (because it may not have performed the same association operation as STA 104), STA 104 may reject (e.g., ignore) completion message 104- 1 and remain active in the wireless network. Thus, the STA 104 may receive a message 112- 0 / 112- 1 over the network. If attacker 108 succeeded in disconnecting STA 104, such a message 112- 0 / 112- 1 would be missed and possibly received by attacker 108.In this way, when a device join a wireless network, it may create a shared secret with a device that controls access to the network (e.g., AP). After the device has joined the network and then receives a disconnect message, such a disconnect message may be subject to a higher level of security by searching for the shared secret. If the shared secret is not present in the disconnect message, the disconnect message may be ignored.While a shared secret created upon joining a network may be used to defend attacks that use invalid messages for disconnection from a network (e.g., a deassociation or deauthentication message), such values may also be used to defend attacks that attempt to join a network using another device ID (e.g., MAC address).FIG. 2 is a signaling diagram illustrating operations of a system 200 according to another embodiment. A system 200 may include operations such as those shown in FIG. 1, and such similar operations are referred to by the same reference numeral, but the leading digit is a "2" instead of a "1.". In some embodiments, a system 200 may be a WLAN compatible system.FIG. 2 may be different from FIG. 1 in that an attacker may transmit an association request 208- 1 using a device ID (e.g., MAC address) of the STA 204. Upon receiving the "counterfeit" association request 208- 1, the AP 202 may decrypt the message to determine whether it is in possession of the shared secret associated with the STA 204 (action 202- 2). Since attacker 208 is not in possession of the shared secret, AP 202 may determine that association request 208- 1 is invalid. An AP 202 may return an association response 202- 3 rejecting the association request. Such rejection may include an indication instructing retry at a later time. Thus, STA 204 may receive a message 212- 0 / 211- 1 over the network that attacker 208 would have intercepted if attacker 208 had succeeded in attempting to join the network.In this way, when a device enters a wireless network, a shared secret can be established with an access device that controls access to the network (e.g., AP). If the access device receives a request to join the network (e.g., association request) from a device determined to have previously joined the wireless network (and not yet left the wireless network), such a message may be subject to a higher level of security by searching for the shared secret. If the shared secret is not present in the request, the request for join may be ignored / rejected.While a shared secret created upon join a network may be used to reject corrupted messages for join (e.g., association) and / or leave (e.g., deassociation / deauthentication) a wireless network, such shared secrets may also be transmitted to other access devices of a larger network to prevent corrupted attacks from different access points to the wireless network.FIG. 3 is a signaling diagram illustrating operations of a system 300 according to another embodiment. A system 300 may include operations such as those shown in FIG. 1, and such similar operations are referred to by the same reference numeral, but the leading digit is a "3" instead of a "1.". In some embodiments, a system 300 may be a WLAN compatible system.A system 300 may differ from that shown in FIG. 1 in that it shows both a first access device (AP1) 302 and a second access device (AP2) 314 that may be in communication with each other to form a larger network 306 (e.g., DS). A STA 304 and AP 1 302 may perform an association operation as described for other embodiments or an equivalent including an association request 304- 0, the creation of secure session context data 302- 0, and an association response 302- 1.With continued reference to FIG. 3, at AP2, an attacker 308 may join a system 300 using a device ID of the STA 304 (action 308- 2). Attacker 308 may request to join a network 308- 1 and receive a response from AP 2 314 (action 314- 0). AP2 314 may proceed with network join operations, including storing cryptographic keys (e.g., PMK) 314- 1 created as attacker 308 joined the network. Thus, using a device ID, attacker 308 has created STA 304 to join a network through an access device (AP2 314) that was not in communication with STA 304.In response to AP1 302 creating a secure session context 302- 0 corresponding to STA 304, AP1 302 may broadcast such secure session context data 302- 4. In some embodiments, such broadcast may be unsolicited. In other embodiments, other access devices, such as AP2 314, may request updates of secure session context data.AP2 314 may receive secure session context data 314-2 for STA 304 (from AP1 302). FIG. 3 shows attacker 308 attempting an association or reassociation operation (referred to as (re)association) 308- 3 with AP 2 314 using previously created login information (e.g., PMK created by association operation 308- 1 / 314- 0) as well as a device ID (e.g., MAC address) of STA 304. However, AP2 314 is now in possession of secure session data for STA 304 due to the unsolicited broadcast 302-4 of AP1 302. Thus, in response to the (re)association request 308- 3, AP 2 314 may further examine the request for additional security data corresponding to secure session data, such as a shared secret. Such an action may include decrypting a portion of the received request. Since attacker 308 is not in possession of the shared secret between STA 304 and AP 1 302, verification 314- 3 fails. If the DS 306 incorrectly believes that the STA 304 is behind AP2 314 (306-0), a (re)association response 314-4 may be returned that may complete a (re)association operation. However, data for transmission is discarded for a timeout period, preventing attacker 308 from illegally receiving such data. Thus, as shown in FIG. 3, the response data 312 that may correspond to the request 310 from the STA 304 is not forwarded to the attacker 308. Further, AP2 314 will discard messages (e.g., packets) corresponding to the secure session data of STA 304 for a timeout period 314- 5.In this way, secure session data created by one access device (e.g., AP) may be transmitted to other access devices of a same extended network (e.g., DS). Thus, an attacker, who is presented as a device connected to an access device, may be detected while attempting to join the network through other access devices of the extended network.While secure session data may be broadcast from one access device to other access devices of a same larger system, in other embodiments, one access device may request secure session data from other access devices of a same extended network. Devices attempting to join the network again may be verified using secure session data requested by other access devices.FIG. 4 is a signaling diagram illustrating operations of a system 400 according to another embodiment. A system 400 may include operations such as those shown in FIG. 3, and such similar operations are referred to by the same reference number, but the leading digit is a "4" rather than a "3". In some embodiments, a system 400 may be a WLAN compatible system.The system 400 and operations show a first access device AP1 402 that broadcasts its ability to establish connections with higher security using secure session data according to the embodiment or equivalents described herein. In the embodiment shown, such action may include transmitting a beacon 402- 5 with an IE that includes data indicative of the secure session capability. The STA 402 may detect the beacon and request an association using secure session data 404- 0. The AP1 402 may return an association response indicating a secure session, 402-1. Such actions may create an encryption scheme for communication between AP1 402 and STA 404, as well as secure session data, including, but not limited to, a shared secret value between AP1 402 and STA 404. AP1 402 and STA 404 may then exchange messages (shown as session traffic 416). In the embodiment shown, the STA 404 may switch between access devices (e.g., APs) based on predetermined criteria including, but not limited to, signal strength, packet loss, or quality of service. In the embodiment shown, roaming 404- 6 by STA 404 may trigger a search for another (e.g., better) extended network access device. As a result, STA 404 may detect broadcast 414- 6 from AP 2 414. Such broadcast 414-6 may take the form described for 402-5 of AP1 402. In some embodiments, AP2 414 may be an access device for a same extended network (e.g., DS) as AP1 402. Upon detecting broadcast 414-6, STA 404 may attempt to join the system again at AP2 414. In the embodiment shown, such an attempt may include a reassociation request 404- 7 to AP2 414, where an IE indicates the secure session data previously created. Such data may not include a shared secret with AP1 402. Upon receiving the request 404- 7, AP 2 414 may transmit a request 414- 7 to AP 1 402 for the secure session context data corresponding to the STA 404. Such a request 414- 7 may use data provided by the re-join request 404- 7 from the STA 404.In response to the request for the secure session context 414-7 of AP2 414, AP1 402 may return a secure session context response 402-6. Such a response 402- 6 may include secure session data created when the STA 404 joined the system 400 via AP1. In some embodiments, such data may include a shared secret value between AP1 402 and STA 404. AP2 414 may receive and store secure session context data received from AP1 402 414-2. Using secure session context data, AP2 414 may verify the re-join request received from STA 404 by ensuring that the message includes a secret code (e.g., a shared secret value with AP1 402) known from or derived from the secure session context data of AP1 402. If the request for recurrence 404- 7 can thus be verified, AP 2 414 may return a response indicating that the request was issued 414- 9. AP2 414 may then permit session data 414-10 with STA 402, and messages may be transmitted between AP2 414 and STA 404 (shown as session traffic 418).In some embodiments, if AP2 414 cannot verify a re-join request 404- 7, AP2 414 may ignore the request or place the request, but discard messages for STA 402 (or what appears as STA 402) for a predetermined amount of time.In this manner, when an access device (e.g., AP) receives a request to join a wireless network indicating that the requesting device was previously connected to the network, the access device may request secure session data from other access devices of the same network. Such secure session data may comprise a shared secret value with another access device corresponding to the requesting device.While embodiments may use secure session data created in a network join operation (e.g., association), such approaches may include decrypting at least a portion of a received message (e.g., to detect a shared secret value). Alternative embodiments may detect mimicking devices without the increased computational resources and / or time required for the inspection of encrypted packet data. Fig. 5 shows an example of such an embodiment.FIG. 5 is a signaling diagram illustrating operations of a system 500 according to another embodiment. A system 500 may include operations such as those shown in FIG. 1, and such similar operations are referred to by the same reference numeral, but the leading digit is a "5" instead of a "1.". In some embodiments, a system 500 may be a WLAN compatible system.FIG. 5 shows an AP 502 and a STA 504 executing a network join operation 520, which in the embodiment shown may include an association request from the STA 504 and a corresponding association response from the AP 502. In contrast to other embodiments described herein, such a network join operation 520 may not create secure session data, such as a shared secret. However, such operations may create an encryption scheme for the communication. Once the STA 504 has successfully joined the system 500, the STA may communicate over the corresponding network. FIG. 5 shows a request 510- 0 from STA 504 that may be transmitted to AP 502, which may forward request 510- 1 to other portions of system 506.As in the case of FIG. 1, an attacker 508 may own a device ID (e.g., MAC address) corresponding to the STA 504. Attacker 508 may transmit a message to STA 504 instructing disconnection from the network. In the example shown, such a message may be a deauthentication or deassociation frame 508- 0 that identifies STA 504 as a destination and AP 502 as a source.In response to the counterfeit message 508-0, the STA 504 may determine whether it is still awaiting communications over the connection corresponding to the disconnect message 508-0 (e.g., whether a corresponding session is in progress). Such determination may take any suitable form including, but not limited to: checking whether a port is still open to a peer (e.g., TCP (Transmission Control Protocol) or UDP (User Datagram Protocol) port); checking whether any BA (Block Acknowledgement) sessions are available; and / or checking whether a host (e.g., AP) has any packets in the queue for transmission to the STA 504.If the STA 504 determines that such a connection is still active, the STA 504 may transmit a message intended to trigger a response on the connection 504-8. Such action may take any suitable form including, but not limited to: a block acknowledge request (BAR), a power save poll message (PS-POLL), and / or a null data packet (NDP). Such a response triggering message is shown as 504-9. A response triggering message 504- 9 may be received by AP 502 and attacker 508. Such a message may trigger a response 502- 7 from AP 502. When attacker 508- 4 responds with its own message 508- 5, STA 504 may detect more than one response 504- 10 and determine that disconnect message 508- 0 is invalid. The STA 504 may ignore the message and remain connected to the system 500. Thus, message data 512- 0 / 1 addressed to STA 504 may be received at STA 504 and not intercepted by attacker 508 (which may attempt to join system 500 using a device ID of STA 504). It is noted that such an approach does not require decrypting portions of received messages and checking for shared secret values or the like. It is noted that while FIG. 5 describes an operation for triggering a single response, alternative embodiments may attempt to trigger more than one response. An STA may then determine that a received message is invalid if a number of received responses exceeds the number of expected responses.In this way, in response to a disconnect from a network message (e.g., deauthentication / deassociation frames), a device may determine whether any corresponding sessions are in progress. When session(s) are running, the device may transmit a message to trigger a response to a device corresponding to the session. If more responses are received than expected, the message may be ignored for disconnection.According to embodiments, devices may transmit and receive messages indicative of secure session capabilities, secure session data, and / or secure session actions. FIGS. 6 to 21 are diagrams of various data frames according to embodiments. In such diagrams, unless otherwise described, similar elements may be referred to by the same reference numerals, but the leading(s) digit(s) corresponds / correspond to the figure number.FIG. 6 is a diagram of a data frame 620 of a secure session notification according to an embodiment. A data frame 620 may be compatible with one or more wireless standards and may include a header 620-0 and a body 620-1. A data frame 620 may be multicast or unicast. A header may include a destination address value and, in some embodiments, a source address value. A body 620-1 may comprise data indicative of secure session capabilities 620-10 of the transmitting device. Secure session capabilities 620-10 may indicate security operations available in addition to those provided by the wireless standard(s) under which a system operates. In some embodiments, secure session capabilities 620- 10 may indicate possible responses to such additional security operations (e.g., ignore or accept actions indicated by messages).In this way, a device that controls access to a network may transmit a message indicating an ability to perform additional security operations to enable compatible devices to join a network and operate under such additional security operations.In some embodiments, additional security features may be a feature provided by a manufacturer.FIG. 7 is a diagram of a WLAN compatible data frame 720 of a secure session notification according to an embodiment. The data frame 720 may include a MAC header 720- 0 and a frame body 720- 1. A MAC header 720- 0 may include a frame type field 720- 00, which may indicate a control frame, which in some embodiments may be a beacon or a probe response. A frame body 720-1 may include a proprietary (VS) secure session IE 720-2, which may include a number of fields. An ID field 720-20 may identify the IE as a proprietary IE (i.e., a value of 221). A length field (LEN) 720- 21 may indicate the length of the remaining fields. An organization unique identifier (OUI) field 720-22 may identify an organization. A type field 720-23 may indicate secure session data.An action field 730- 3 may indicate actions that an AP may perform if secure session verification fails. In the embodiment shown, action field 730- 0 may be a bitmap, wherein different bit positions 720- 31 indicate different actions 720- 30. FIG. 7 includes descriptions of actions 720- 32, which may include rejecting a connection request or discarding messages for a STA for a timeout period.In this way, a WLAN AP may transmit a beacon or probe response with a proprietary IE that indicates which types of secure session responses (to a failed verification) the AP may provide.FIG. 8 is a diagram of a data frame 822 of a secure session request according to an embodiment. A body 822- 1 may include data requesting access to a network using secure session capabilities 822- 10. Secure session capabilities may include additional security checks or actions taken in response to particular messages received. In some embodiments, certain messages may include messages requesting connection to a network and / or messages instructing disconnection from a network.In this way, in response to an access device indicating joining operations that may include additional security operations, a device may issue a request to join a network using such additional security operations.FIG. 9 is a diagram of a WLAN compatible data frame 922 of a secure session request. A frame type field 922- 00 of a MAC header 922- 0 may indicate a management frame and, in some embodiments, an action frame. A MAC header 922- 0 may also indicate that a frame is a protected management frame (PMF).A frame body 922- 1, which may be encrypted, may include a secure session request IE 922- 2 having a number of fields. The ID, LEN, and OUI fields (922-20 through -22) may correspond to those described in FIG. 7. An action field 922- 23 may indicate an action resulting from a failure of a secure session, including, but not limited to, rejecting a request indicated by a message or discarding session packets for a timeout period. A timeout field 922- 24 may define the timeout period (e.g., for discarding packets). A session type field 922- 25 may indicate a session type (e.g., UDP or TCP). A session data lens 922- 26 may define a size of an optional session data lens 922- 3. Optional session data field 922- 3 may provide additional data for one or more sessions. As just one example, for an IPv4 type session, session data may include a local IP address 922- 30, a local port 922- 31, a remote IP address 922- 32, and a remote port 922- 33. In some embodiments, session data field 922- 3 may include data for more than one session.In this way, a WLAN STA request may include a secure session request IE that may indicate secure session responses, values (e.g., timeout values), and data identifiers.FIG. 10 is a diagram of a data frame 1024 of a secure session response, according to an embodiment. A body 1024- 1 may include data indicating a status of a request to join a network to establish a connection with secure session capabilities (e.g., accepted or rejected).In this manner, in response to a request to join a network having secure session capabilities, an access device may return a message indicating a status of such a connection.FIG. 11 is a diagram of a WLAN compatible data frame 1124 of a secure session response. A frame type field 1124- 00 of a MAC header 1124- 0 may indicate a management frame (e.g., an action frame) and that the data frame is a PMF 1124- 01. A frame body 1124- 1, which may be encrypted, may include a secure session response IE 1124- 2 having a number of fields. The ID, LEN, and OUI fields (1124-20 through -22) may correspond to those described in Figure 7. A type field 1124-23 may indicate the IE type (i.e., a response to a secure session request). A status field 1124- 24 may indicate (e.g., accept or reject) a response to a request. A secure session ID field 1124-25 may include a unique value corresponding to the session corresponding to a secure session request.In this way, a WLAN AP may respond to a secure session request with a response that includes an IE that indicates a status of the request as well as a unique ID corresponding to a secure session.Embodiments may include messages containing security values to enable a higher level of security in wireless communications to address attacks using messages that mimic a device ID. Such security values may include a value that is a shared secret established between two devices when they initially join a network.FIG. 12 is a diagram of a data frame 1226 that may include secure session context data, according to an embodiment. Such a data frame may be a message from a device that controls access to a network (e.g., AP) as well as a device that attempts to join or re-join a network (e.g., STA). A body 1226-1 may include secure session data 1226-2 including a device ID 1226-24 and a secret value 1226-25. A device ID 1226-24 may be the one created for a device in previous communications. A secret value 1226-5may be a value created in previous communications (e.g., when joining a network) and may be a value shared between two devices. At least one secret value 1226-25 may be encrypted. Upon receiving the data frame 1226, a device may decrypt the secret value and determine whether it matches its own secret value. This can provide additional security because an fraudster using a device ID 1226-24 is not in possession of such a secret value 1226-25.In this manner, messages from a device operating over a secure session connection may include encrypted shared secret values to prevent fraudulent messages from affecting network operations.FIG. 13 is a diagram of a WLAN compatible data frame 1326 with a secure session identity IE 1326-2. A frame type field 1324-00 of a MAC header 1324-0 may indicate a management frame. Such a management frame value 1326-0 may indicate a data frame originating from a STA (e.g., (re)association request) or an AP (e.g., deauthentication / deassociation frame).A frame body 1326-1, which may be encrypted, may include a secure session identity IE 1326-2 having a number of fields. The ID, LEN, and OUI fields (1326-20 through -22) may correspond to those described in Figure 7. The type field 1326-23 may indicate the IE type (secure session identity). A previous MAC field 1326-24 may be a MAC address from a last successful association. A secret code field 1326-25 may include a secret value established between an AP and a STA in a previous session (e.g., association). In some embodiments, a secret code may have a form protected by encryption, including, but not limited to, a cryptographic algorithm and / or a cryptographic hash function. In some embodiments, a secret code may be a PMK and / or PTK created in a recent session, and thus both the AP and the STA of the session are known, but not an authenticator using a MAC address of the AP or the STA.In this way, a WLAN AP or a WLAN STA may include a secure session identity IE in messages to enable a receiving device to confirm the presence of a shared secret for additional security, comprising preventing fraudster attacks using the MAC address of a device associated with or previously associated with a wireless system.After creating secure session context values upon join a network, embodiments may include update messages for updating such secure session context values.FIG. 14 is a diagram of a data frame 1428 of a secure session update, according to an embodiment. A body 1428-1 may include data indicating changes in secure session data 1428-10. In response to receiving such a data frame 1428, a device may update one or more parameters of the corresponding secure session.In this way, parameters of a secure session may be updated if features of a connection change.FIG. 15 is a diagram of a WLAN compatible data frame 1526 of a secure session update according to an embodiment. A MAC header 1528-0 may indicate a management frame, such as an action frame, and that the data frame is protected 1528-01 (e.g., a PMF).A frame body 1528-1, which may be encrypted, may include data for updating features of a secure session. A field 1528-20 may indicate a data frame type (i.e., a secure session update). A secure session ID field 1528-21 may include a secure session ID created in previous communications. An OP field 1528-22 may indicate an operation type (e.g., add or delete secure session data). The action, timeout, session type, and secure data len fields 1528-23 through 1528-26 may take the form of those described in Figure 9, or an equivalent. In the same manner, optional session data field 1528-3 and its local IP, local port, remote IP and remote port 1528-30 through 33 fields may take the form of those described in Figure 9.In this way, a WLAN STA may transmit updated values for a secure session to an AP in a data frame. In some embodiments, such a data frame may be transmitted by a STA prior to initiating a session to ensure that such a session may be a secure session as described herein or an equivalent.FIG. 16 is a diagram of a secure session update acknowledgment (ACK) data frame 1630, according to an embodiment. A data frame 1630 may be transmitted in response to a secure session update data frame such as that of Fig. 14. A body 1630- 1 may include data 163- 2 confirming a secure session update data frame. Such data 1630-2 may indicate whether or not an update operation was successful.In this way, a secure session update data frame can be answered with parameters that can be updated if features of a connection change.FIG. 17 is a diagram of a WLAN compatible data frame 1730 of a secure session update ACK according to an embodiment. A MAC header 1730-0 may indicate a management frame 1730-00, such as an action frame, and that the data frame is protected 1730-01 (e.g., a PMF).A frame body 1730- 1, which may be encrypted, may include a secure session update ACK 1730- 20 field, which may indicate that an update operation has been completed. A Secure Session ID field 1730-21 may acknowledge the session corresponding to the received Secure Session Update data frame.In this way, a WLAN AP may return a Secure Session ACK in response to receiving a Secure Session Update data frame.As noted herein for embodiments, an access device that controls access to a network may create secure session data with a device joining a network and share such secure session data with other access devices. In some embodiments, an access device may request secure session data from other access devices.FIG. 18 is a diagram of a secure session data request frame 1832, according to one embodiment. A data frame 1832 may be compatible with one or more wireless standards and may include a header 1832-0 and a body 1832-1. A body 1832-1 may include data indicating one or more device IDs 1832-10 for which secure session data is sought.In this manner, one access device may request secure session data from another access device to perform additional security operations.FIG. 19 is a diagram of a WLAN compatible secure session context request frame 1932, according to an embodiment. In some embodiments, data frame 1932 may be a layer 2 (L2) data frame. A MAC header 1932-0 may indicate a control frame (e.g., request) 1932-00. A destination MAC address field 1932-01 may be a broadcast address (for all other APs of a DS) or a unicast address (directed to a particular AP of a DS). A source MAC address field 1932-02 may be an address of a requesting AP. An Ethertype field 1932-03 may indicate a request associated with a secure session. A frame body 1528-1 may include an LEN field 1932-10, which may indicate a length of a frame body. A frame type field 1932-11 may indicate a request. A client MAC address field 1932-12 may indicate a MAC address for a STA of interest.In this way, a WLAN AP may request secure session data for a STA of interest from one or more other APs of the same DS. Such a request may be issued in response to communications from a STA requesting reassociation or association.FIG. 20 is a diagram of a secure session data response frame 2034, according to an embodiment. A body 2034-1 may include data indicating one or more device IDs 2034-10 for which secure session data is searched, as well as secure session data corresponding to the device ID. In some embodiments, such data may include a shared secret 2034-11 corresponding to the device ID 2034-10.In this way, an access device can transmit secure session data for a device ID specified in a secure session data request.FIG. 21 is a diagram of a WLAN compatible secure session context request frame 2134, according to an embodiment. A MAC header 2134-0 may indicate a control frame (e.g., request) 2134-00. A destination MAC address field 2134-01 may be a unicast address (e.g., address of an AP of a same DS requesting secure session context data) or a multicast address (e.g., message for all APs of a DS). A source MAC address field 2134-02 may correspond to the AP sending the data frame 2134. An Ethertype field 2134-03 may indicate a response associated with a secure session. A frame body 2134-1 may include an LEN array 2134-10 that may indicate a length of a frame body. A frame type field 2134-11 may indicate a response. A client MAC address field 2134-12 may indicate a MAC address for a STA corresponding to a request. A session type field 2134-13 may indicate a session type (e.g., UDP or TCP). An action field 2134-14 may indicate a type of action performed in response to a failure of secure session verification (e.g., rejection of a connection, discarding session packets for a timeout period). A timeout field 2134-15 may provide a timeout value for actions noted herein. A session data length field 2137-17 and optional session data fields 2134-2, 2134-20 to 2134-23 may correspond to those shown in Fig. 15 as 1528-26, 1528-3 and 1528-30 to 1528-33. In some embodiments, a frame body 2134-1 may include additional secure session data including a shared secret.In this way, a WLAN AP may provide secure session context data of an associated (or previously associated) STA to another AP of a same DS.While the systems and devices described herein depict various methods, additional methods will now be described with reference to flowcharts. Such methods may be performed by circuitry of devices and / or systems described herein.FIG. 22 is a flow diagram of a method 2240, according to an embodiment. A method 2240 may be performed by a wireless device that enters a network and / or controls access to a network. A method 2240 may include performing a network join operation that adds a wireless device to a wireless network 2240-0. Such an action may include the following steps suitable for an existing wireless standard. Once a device has joined a network, communications may take place over the wireless network according to the appropriate standard(s).Upon receiving a disconnect message, a method 2240 may determine whether the message includes a valid device address 2240-1. In contrast to some conventional operations that may separate from a network in response to such a separation message, a method 2240 may further evaluate the message for false origin 2240-2. Such an action may include performing one or more additional security operations to ensure that the separation message is not from a fraudster. Such additional security operations may include, but are not limited to, checking for a shared secret value that was created as a device attached to a network and transmitting a request to the putative source of the disconnect message to trigger a response.Based on further evaluations, a method 2240 may determine whether a disconnect message is valid (e.g., not transmitted by a fraudster), 2240-3. If the disconnect message is determined to be valid (J of 2240-4), the message may be allowed and a device may be allowed to disconnect from the network 2240-4. However, if it is determined that the message is not valid (N of 2240-4), a method 2240 may ignore the disconnect message 2240-5. In some embodiments, such ignoring may be an action in addition to those included in the wireless standard under which the device operates.In this way, in response to a message to disconnect from a network, a device may perform security operations in addition to detecting that the message indicates that it originated from a valid device ID.FIG. 23 is a flow diagram of a method 2340 according to another embodiment. A method 2340 may be performed by a device associated with a wireless network and / or a device controlling access to a wireless network. A method 2340 may include performing a wireless network association operation that may create an encryption system for the devices of the wireless network 2340-0. Such an action may include creating one or more encryption keys according to an agreed upon standard.A method 2340 may include establishing a shared secret between two devices. Such an action may include determining a secret value that may be unique to a connection. In some embodiments, a shared secret may be an encryption key or a value derived from an encryption key. However, a secret value may be any other suitable value.A method 2340 may determine whether a deassociation message is received (2340-2). A deassociation message may be a message instructing a device to terminate communications with the network. When a deassociation message is received (J of 2340-2), a message may be decrypted 2340-3. Such action may include decrypting an entire payload or a portion thereof using a decryption method created at the association. If the decryption of a deassociation message does not disclose a shared secret (N of 2340-4), a received deassociation message may be ignored 2340-5. If the decryption of a deassociation message reveals a shared secret, the deassociation operation indicated by the deassociation message may be performed 2340-6.In this way, a wireless device may decrypt the message upon receiving a deassociation message. If decryption does not disclose a shared secret, the deassociation message may be ignored.FIG. 24 is a flow diagram of a method 2440 for WLAN STA operations, according to an embodiment. A method 2440 may include determining whether an AP beacon is detected with a VS secure session IE 2440-0. Such action may include detecting an AP beacon with a proprietary field that identifies secure session capabilities provided by an AP. In some embodiments, a VS secure session IE may take the form of that shown in Figure 7, or an equivalent. In the embodiment shown, if an AP beacon is not detected with a VS secure session IE (N of 2440-0), a method 2440 may transmit a probe request with a VS secure session IE, 2440-1. Such a VS Secure Session IE may take the form of that described for the 2440 0 beacon.If a corresponding probe response is received (J of 2440-2) or an AP beacon has been detected with a VS secure session IE (J of 2440-0), a method 2440 may transmit an association request including a request for secure session operations 2440-3. Such a response may include an indication of a type of action performed in response to results of secure session verification (e.g., ignoring, discarding packets). When a corresponding secure session association response is received (J of 2440-4), a secure session association operation may be completed. It will be appreciated that a secure session association operation may include creating the encryption scheme for the corresponding system.It is noted that while method 2440 shows a STA that can both search for secure session AP beacons and transmit secure session probe requests, alternative embodiments may only perform such an operation to detect a secure session-capable AP. Further, such actions may depend on an operating mode or configuration of such a STA.Once secure session association succeeds (J of 2440-4), a method 2440 may create a shared secret 2440-5. Such action may include any of the ones described herein or equivalents including use of a PMK and / or PTK generated during association.In the embodiment shown, a method 2440 may include determining whether there is a change in the secure session context 2440-6. In some embodiments, such action may include monitoring data included in a VS secure session ID for changes. If there are changes to the secure session data (J of 2440-6), a method 2440 may transmit a secure session update frame 2440-7. Such a message may inform an AP of secure session changes. In some embodiments, such a message may take the form of that shown in Figure 15. Although not shown in FIG. 24, a method 2440 may include continuing to transmit secure session update messages until an acknowledgement is received from one or more target AP(s).In the embodiment shown, a method 2440 may also include determining when a roaming action has caused a STA to decided to connect to another AP 2440-8. Such action may include roaming compatible with a WLAN standard. When a STA has performed roaming (J of 2440-8), a (re)association request with a VS secure session IE may be transmitted to the target AP, 2440-9. Such action may follow those of 2440-3. If a corresponding association response is not received (N of 2440-10), a method 2440 may continue roaming operations (e.g., continue to search for reassociation).In the embodiment shown, if a corresponding association response is received (J of 2440-10), a method 2440 may determine whether a deassociation or deauthentication (deassoci / deauthentic) message is received 2440-11. In some embodiments, such action may include determining that such a message includes a valid source MAC address. When a deassoc / deauth message is received (J of 2440-11), a method 2440 may determine whether such a message includes a shared secret, 2440-12. In some embodiments, such an action may include decrypting the deassoc / deauth message. In some embodiments, additional operations (e.g., decryption algorithm, cryptographic hash function) may be performed on a decrypted value. If it is determined that a deassoc / deauth message does not include a shared secret (N of 2440-12), a method 2440 may ignore the message 2440-13. If a deassoc / deauth message is determined to include a shared secret (J of 2440-12), a method 2440 may delete secure session data for the connection, 2440-14 (which may include any one or more shared secrets), and the STA may perform the deassoc / deauth operation indicated by the message, 2440-15.In this way, a WLAN STA may determine when an AP has secure session capabilities and may create a shared secret when associated with the AP. If the STA receives a deassociation or deauthentication message, if the message does not include the shared secret, the message may be ignored. An STA may update one or more APs if secure session data has changed.FIGS. 25-0 and 25-1 show a flow diagram of a method 2540 according to another embodiment. The flow chart shown in FIGS. 25-0 may be connected to that of FIGS. 25-1 at circuits 42 and 44. A method 2540 may be executed by an AP to provide security features for a secure session to a corresponding BSS comprising a BSS that is part of a DS.Referring to FIGS. 25-0, a method 2540 may include transmitting a VS secure session IE in a beacon or probe response 2540-0. Such action may notify STAs of secure session capabilities provided by an AP. In some embodiments, such a transmitted message may take the form of that shown in Figure 7 or an equivalent.When an association request is received that also requests a secure session (J of 2540-1), a method 2540 may create a shared secret 2540-2 corresponding to a requesting STA and return an association response 2540-3 indicating the secure session parameters 2540-3. In some embodiments, this may include a message with a VS secure session IE as described herein, or equivalents. Optionally, a method 2540 may include transmitting the secure session context data corresponding to the associating STA to other APs 2540-4. In some embodiments, this may include transmitting such information to other APs of a same DS. As can be seen from embodiments herein, such transmission of secure session context data may be unsolicited multicast and / or unicast. Such unicast transmission may be unsolicited or in response to a request from another AP.A method 2540 may also include determining if secure session update frames are received 2540-5. In response to receiving such a data frame, a method 2540 may update secure session data for the corresponding STA 2540-6. A method 2540 may determine whether a reassociation request or association request is received from a previously or currently associated device 2540-7. When such a (re)association request is received (J of 2540-7), a method 2540 may determine whether the message includes a shared secret corresponding to the requesting STA 2540-8. Such action may include any of the equivalents described herein, including decrypting a portion of the message. If no shared secret is included in the (new) association request (N of 2540-8), a method 2540 may take an action based on secure session data created in an initial association 2540-9. In the embodiment shown, such an action may include rejecting the request 2540-90, or else accepting the request, but discarding packets corresponding to the session for a timeout period 2540-91. If a shared secret is included in the (new) association request (J of 2540-8), a method 2540 may accept the request 2540-10.Referring to FIGS. 25-1, a method 2540 may include determining whether a deassoc / deauth message is received 2540-11. When such a message is received (J of 2540-11), a method 2540 may determine whether the message includes a shared secret 2540-12. Such action may include any of the equivalents described herein. If no shared secret is included in the message (N of 1540-12), the message may be ignored, 1540-13. If a shared secret is included in the message (J of 1540-12), the secure session data corresponding to the Deassoc / Deauth message may be deleted, 1540-14, and the corresponding STA may be deassociated or deauthentified, 2540-15. Optionally, a method 2540 may include transmitting a notification to other APs regarding the deassoc / deauth operation 2540-16.In this way, an AP can inform potential associating STAs of their secure session capabilities with a broadcast or unicast message. After association with a STA, an AP may create a shared secret with the STA. If a deassociation or deauthentication message is received for the STA, if such a message does not include the shared secret, the message may be ignored. If a reassociation request is received, if such a request does not comprise the corresponding shared secret, the request may be ignored, or alternatively may be granted, but packets for the corresponding STA are discarded for a timeout period.According to embodiments, APs may communicate secure session capabilities to other APs of the same system (e.g., DS). FIG. 26 is a flow diagram 2640 illustrating a method according to such an embodiment. It should be understood that the actions of FIG. 26 may be in addition to those shown in FIGS. 25-0 and 25-1. A method 2640 may include determining whether secure session context data is received 2640- 0. Such a secure session context may comprise a shared secret. Such action may include receiving a message from another AP. When such a message is received, the secure session context data may be stored 2640-1. It should be appreciated that such data may identify a STA (e.g., by a MAC address and / or other session data) and thus may allow an AP to perform additional actions for a secure session if such a STA searches for reassociation. Optionally or in alternative embodiments, a method 2640 may include transmitting a request to other APs for secure session context data 2640- 2.A method 2640 may include determining whether a notification regarding the deassoc / deauth of a STA associated with another AP has been received 2640- 3. When such a notification is received (J of 2640-3), a method 2640 may delete secure session data corresponding to the STA 2640-4.In this way, an AP can receive and update secure session data from other APs.While embodiments may include decryption of data frame fields to verify a shared secret, other embodiments may use transmission of messages to trigger an additional security response.FIG. 27 is a flow diagram of a method 2740 according to another embodiment. A method 2740 may be performed by a device receiving a message indicating that it should disconnect from a network. A method 2740 may include performing a wireless association operation that creates a wireless network device encryption system 2748-0. Such action may comprise performing the steps according to a predetermined standard to join a network.A method 2740 may determine whether a disconnect message is received 2740-1. A separation message may take the form of any of the equivalents described herein. When a separation message is received (J of 2740- 1), a method 2740 may determine a putative source of the separation message 2640- 2. Such action may include examining data inherent to the received message (e.g., source address and / or other session data). A method 2740 may transmit a message to trigger a response from the putative source of the separation message 2740-3. Such a message may take any suitable form, depending on the standard under which a system is operating.A method 2740 may determine if more responses than expected are received 2740-4. If more responses than expected are received (J of 2740-5), the message may be ignored for disconnect 2740-5. Such a result may occur when a fraudster issues one or more responses in addition to a valid device. If a number of received responses is as expected (N of 2740-5), a disconnect operation may be performed 2740-6.It is noted that a method 2740 may determine the presence of an fraudster without having to examine (e.g., decrypt) a body of a message. This may have a lower computational requirement than embodiments that perform a shared secret check in a body of a data frame.In this way, a fraudster device sending a disconnect message may be detected by sending a message to the putative source of the message. If a fraudster and valid device send responses, more responses than expected may be received indicating the presence of a fraudster and the disconnect message may be ignored.FIG. 28 illustrates a method 2840 of detecting an invalid deassoc / deauth message, according to an embodiment. A method 2840 may be performed by a WLAN compatible STA. A method 2840 may include receiving a deassoc / deauth message 2840-0. A method 2840 may determine whether a session corresponding to the message is still open 2840-1. Such action may include any of those described herein, including, but not limited to: checking for an open TCP / UDP port corresponding to the putative source of the message, determining whether any BA sessions corresponding to the putative source are available, and / or determining that an AP has downloaded data frames in the queue.If a session is still open (J of 2840-1), a method 2840 may transmit a frame to trigger a response from a putative source of the deassoc / deauth message 2840-2. Such an action may include any of those described herein, including, but not limited to, transmitting a BAR, PS Poll, or NDP. If no response(s) is received (N of 2840-3), a method 2840 may continue to attempt to trigger a response. When one or more responses are received, a method 2840 may determine whether a number of received responses exceeds an expected number 2840-4. In the embodiment shown, such an action may include determining whether more than one response is received. Receipt of more than one response (J of 2840-4) may indicate the presence of an fraudster, such as a device using a MAC address of an AP, and the deassoc / deauth message may be discarded 2840-5.If a number of responses is as expected (N of 2840-4) or there is no open session corresponding to the deassoc / deauth message (N of 2840-1), a method 2840 may process the deassoc / deauth message 2840-7.In this manner, when a STA receives a Deassoc / Deauth message for an open session, the STA may send a message to the putative source of the message to trigger a response. If more responses are received than expected, the STA may discard (e.g., ignore) the Deassoc / Deauth message.While embodiments have described systems, methods, and corresponding devices, additional devices will now be described.FIG. 29 is a block diagram of a wireless device 2950, according to an embodiment. A wireless device 2950 may control access to a network and / or may be a device that joins a network. In some embodiments, a device 2950 may be an AP or a STA of a network comprising a WLAN compatible AP or STA in a BSS or DS. A device 2950 may include input / output (IO) circuits 2952, control circuits 2954, and wireless circuits 2956. IO circuits 2952 may enable a device 2950 to communicate with other systems and / or a user, and may include any suitable communication circuits and / or interfaces including wired and / or wireless circuits / interfaces.The control circuitry 2954 may include any suitable circuitry for performing wireless network access operations as described herein, and equivalents. The control circuitry 2954 may include, but is not limited to, one or more processors, custom logic circuits, programmable logic circuits, and / or machine learned / learning systems. The control circuitry 2954 may include circuitry for processing association, reassociation, and / or reauthentication ((New)Assoc. / (New)Au.) operations 2958, as well as deassociation and / or deauthentication (Deassoc. / Deauth.) messages 2960. Processing (New)Assoc. / (New)Au operations 2958 may allow a device to join a network, including creating an encryption scheme. In addition, a shared secret may be created 2958-0. Such action may include any of the ones described and equivalents herein.Processing deassoc / deauth messages 2960 may include decrypting messages to determine a shared secret 2960-0. Such an action may include decrypting according to a generated decryption scheme to determine a shared secret or a value used to determine a shared secret. In some embodiments, determining a shared secret may be a security operation in addition to those provided by a standard under which a device operates. Processing deassoc / deauth messages 2960 may also include operations to ignore a deassoc / deauth message 2960-1. In some embodiments, such an operation may allow a device to ignore a deassoc / deauth message that otherwise corresponds to a standard under which the device operates. Additionally or alternatively, processing a Deassoc / Deauth message, 2960-0, may comprise generating a message to trigger a response from a putative message source, 2690-2. Such operations may follow the equivalents described herein.Wireless circuitry 2956 may include circuitry compatible with one or more standards, including public and / or private standards. In some embodiments, wireless circuitry 2956 may be compatible with one or more IEEE 2902.11 or related standards. Wireless circuitry 2956 may be connected to an antenna system 2964.In some embodiments, IO circuits 2952, control circuits 2954, and wireless circuits 2956 may be part of a same integrated circuit substrate 2962.In this manner, a wireless device may include control circuitry for creating and storing a shared secret with another device in a network join operation. Upon receiving a deassociation / deauthentication message, the control circuitry may decrypt the message and compare data in the decrypted data to the shared secret. Additionally or alternatively, the control circuitry may issue a message to trigger a response from a putative source of the message.FIG. 30 is a block diagram of an apparatus 3050 according to another embodiment. In some embodiments, a device 3050 may be an implementation of that shown in FIG. 29. In some embodiments, a device 3050 may be a WLAN compatible AP that may provide secure session capabilities for a BSS and / or DS. A device 3050 may include control circuitry 3054, Wi-Fi circuitry 3056, and optionally other wireless circuitry 3080, and bridge interface circuitry 3078, interconnected via a backplane and / or bus 3076.The control circuits 3054 may include memory circuits 3054-1 and processor circuits 3054-0. The memory circuits 3054-1 may include any suitable memory circuits including non-volatile memory, volatile memory, and / or combinations thereof. According to embodiments, memory circuitry 3054-1 may include circuitry that is part of device 3050 and / or memory circuitry external to device 3050, but which may be accessed by processor circuitry 3054-0 according to a wired or wireless protocol.The memory circuitry 3054-1 may store data to enable the various operations of the wireless device 3050, including enabling secure session operations that may address potential attacks using the MAC address of another device. The memory circuits 3054-1 may be configured to store code (e.g., firmware) 3072 executable by the processor circuits 3054-0 to provide the various processor circuit operations described herein. The memory circuits 3054-1 may also store secure session data 3074. Secure session data 3074 may include, but is not limited to, one or more shared secret(s) 3074-0 and / or timeout values 3074-1. Such values 3074-0 / 1 may take the form of any of the equivalents described herein.The processor circuits 3054-0 may execute code 3072 stored in the memory circuits 3054-1 to provide various functions to the device 3050. Operations provided by the processor circuitry 3054 may include, but are not limited to, executing association / authentication (Assoc / Auth) operations 3066, processing (New)Asc / (New)Au requests 3058; executing secure session operations 3068, executing DS operations 3070; and processing deassoc / Deauth messages 3060. Performing Associate / Authenticate operations 3066 may include actions compatible with one or more IEEE 802.11 standards. However, unlike conventional AP operations, the deassoci / deauth processing 3066 may include generating VS secure session beacons and / or probe responses, 3066-0, creating a unique shared secret with each associating STA, 3066-1, and generating secure session association responses, 3066-2. Such actions may include any of those described herein or equivalents. In some embodiments, such operations may include generating data frames as shown in FIGS. 7 and 11.Processing (New)Assoc. / (New)Au.requests 3058 may include decrypting such shared secret messages 3058-0. In some embodiments, such operations may include storing the received request frame, determining a source of the request (e.g., source MAC address), decrypting a frame body of the request according to an encryption method created by a previous association operation. A decrypted field may then be compared to a stored shared secret corresponding to the source of the request to verify the request. In contrast to conventional operations, if secure session verification fails, processing (New)Assoc. / (New)Au.requests 3058 may include accepting the request, but may further include discarding packets destined for the source of the request for a timeout period, 3058-1.Secure session processing 3068 may include operating on secure session data created during an association operation. Such secure session data may include values in addition to those established by a selected IEEE 802.11 wireless standard. Secure session processing 3068 may include processing update frames, 3068-0. In some embodiments, such operations may include receiving a data frame and determining, by an IE, which secure session data is to be updated (e.g., added, deleted, replaced). Secure session processing 3068 may also include deleting secure session data 3068-1. DS operations 3070 may include operations for sharing secure session data between APs of a DS. Such operations may include transmitting secure session data for other APs, 3070-0, as well as processing secure session data received from other APs, 3070-1.Processing deassoc / deauth messages 3060 may include decrypting such shared secret messages 3060-0 as described for embodiments herein. In contrast to conventional operations, if secure session verification fails, processing deassoc / deauth messages 3060 may include ignoring such messages (as opposed to performing operations indicated by such messages).The wireless circuitry 3056 may provide wireless communications compatible with one or more wireless standards. The wireless circuits 3056 may include MAC layer circuits 3056-0, physical layer (PHY) circuits 3056-1, and RF circuits 3056-2. Such circuits (3056-0, -1, -2) may be compatible with one or more IEEE 802.11 wireless standards on any suitable band including, but not limited to, the 2.4 GHz, 5 GHz, and / or 6 GHz band.The IO circuits 3052 may input or output signals that may enable control of a device 3050 from sources external to the device in any suitable manner. In some embodiments, IO circuits 3052 may include serial communication circuits including, but not limited to, interfaces compatible with a serial digital interface (SDI), a universal serial bus (USB), a universal asynchronous receiver transmitter (UART), I2C, or I2S.Bridge interface circuits 3078 may enable communications between wireless circuits 3056 and other wireless circuits 3080. In some embodiments, such communications may control which wireless circuits (3056 or 3080) may operate on a common medium (e.g., 2.4 GHz band). Other wireless circuitry 3080 may be one or more wireless circuitry compatible with a standard other than WLAN, including, but not limited to, one or more BT standards, one or more IEEE 802.15.4 or related standards, and / or one or more cellular network standards.A device 3050 may operate in conjunction with an antenna system 3064 having one or more antennas compatible with one or more wireless standards including those of another wireless portion 3080 if included.In some embodiments, the IO circuits 3052, the control portion 3054, and the wireless circuits 3056 may be formed with a same integrated circuit substrate 3062.In this way, a WLAN compatible AP may provide additional security capabilities using secure session data created in an association operation that may include a shared secret. A received message may be verified by checking for shared secret data. If the verification fails, a message may be ignored or another action may be taken that is in addition to the standard under which the AP is operating.FIG. 31 is a block diagram of an apparatus 3150 according to another embodiment. In some embodiments, a device 3150 may be an implementation of that shown in FIG. 29. In some embodiments, a device 3150 may be a WLAN compatible STA that can associate with and then operate under secure session capabilities. A device 3150 may comprise elements such as those in Fig. 30, and such similar elements are referred to by the same reference numerals, but the leading numerals are "31" instead of "30".Operations provided by the processor circuits 3154 may include, but are not limited to, (re)association processing 3158, update operations 3182, roaming operations 3184, and deassoci / deauth processing 3160. Additionally or alternatively, processor circuits 3154-0 may perform response triggering operations 3186. The (re)association processing 3158 may include operations related to associating or reassociating with a BSS. Such processing may include detecting an AP beacon or probe response indicating secure session capabilities 3158-0. Such actions may include detecting a secure session IE included in a beacon. Additionally or alternatively, a device 3050 may generate a secure session probe 3158-2 to trigger corresponding probe responses from APs having secure session capabilities. The update operations 3182 may include generating secure session update frames, 3182-0. Such data frames may be transmitted as described herein if secure session data for a device 3150 has been changed. Such data frames may be multicast or unicast.Roaming operations 3184 may be performed by device 3150 in response to signal conditions to enable device 3150 to search for other APs with which it may be associated if a connection to a current AP has become undesirable. Unlike conventional operations, roaming operations 3184 may include generating reassociation requests with secure session data that includes, but is not limited to, a shared secret 3184-0.Processing deassoc / deauth messages 3160 may include decrypting received messages to check for a shared secret 3160-0. Unlike conventional STA operations, processing deassoc / deauth messages 3160 may include ignoring such messages 3160-1 if secure session verification fails. Additionally, upon successful deassociation / deauthentication, secure session data may be deleted 3160-20.In some embodiments, processing deassoc / deauth messages 3160 may include response triggering operations 3186. Such operations may include determining whether a deassoc / deauth message corresponds to an active session, 3186-0, transmitting a response triggering frame, 3186-1, and tracking a number of responses, 3186-2, received from a response triggering frame.In this way, a STA device may provide additional security capabilities using secure session data created in an association operation. A STA may update such data with transmissions to an AP and use such data in a reassociation operation and to verify deassoci / deauth messages. Alternatively, a STA device may trigger responses from a putative source of a deassoc / deauth message to detect a fraudster.While embodiments may include systems and devices with various interconnected components, embodiments may also include unified devices having the ability to protect wireless networks from attacks that utilize a device address of a device already associated with the network. FIG. 32 illustrates an example of a packaged single-chip wireless device 3250, according to an embodiment. Such apparatus 3250 may include circuitry for performing secure session operations as described herein and equivalents. In some embodiments, a device 3250 may include circuits such as those shown in any of FIGS. 29-31.However, it should be appreciated that a device according to embodiments may include any other suitable packaging type of integrated circuit as well as directly bonding a device chip to a circuit board or substrate.In this way, a wireless device that can protect from insider attacks may be included in a single integrated circuit device.While embodiments may enjoy broad application in various wireless systems, vehicle systems may benefit from the resistance to insider information attacks as described herein. FIG. 33 illustrates a motor vehicle system 3300 according to an embodiment. An automotive system 3300 may include one or more subsystems 3300-0 (e.g., an in-vehicle infotainment system), which may include a wireless device 3350 in the form of any of the or equivalents described herein. In some embodiments, such a wireless device 3350 may operate as a "soft AP" and / or a STA.In this way, vehicles may include a vehicle wireless system that may prevent insider information attacks that use addresses of devices already associated with the vehicle wireless system.FIG. 34 illustrates a system 3400 according to another embodiment. A system 3400 may include two or more APs 3402, 3414, as well as a number of STAs 3404-0 through 3404-5. The APs 3402 / 3414 and / or STAs (3404-0 through -5) may include devices as described herein and / or circuitry for performing the various methods described herein.The APs 3402 / 3414 may create secure session data after association with STA, as described herein or equivalents. Such secure session data may include shared secrets 3474-0 to 3474-5. The APs 3402 / 3414 may communicate with each other over a connection 3490, which may be wireless or wired. Via such a link 3490, the APs 3402 / 3414 may update secure session data that they create when a STA associates with a DS. Thus, the AP 3414 may own the same shared secret as the AP 3402.In some embodiments, the STAs (3404-0 through -5) may be included in Internet of Things (IoT) type devices including, but not limited to, medical devices 3404-0 / 1, instrumentation devices 3404-2, security devices 3404-3 / 4, or lighting devices 3404-5. However, such wireless devices are provided as an example, and any suitable wireless device may benefit from additional security operations as described herein or equivalents. The STAs (3404-0 to -5) may associate with a network by the AP 3402. Each STA (3404-0 to -5) may have a corresponding shared secret 3474-0 to 3474-5.When an attacker 3408 attempts to force deassociation of a STA (3404-0 through -5) with a counterfeit deassoci / deauth frame 3408-0, a STA (3404-0 through -5) may detect the attacker by checking such a message for a shared secret and / or triggering a response from the attacker 3408. When an attacker 3408 requests to join a system 3400 at the AP 3402 or 3414, each AP (3402 / 3414) can check such a request for a shared secret (3474-0 to -5). If such a shared secret is missing, the request may be ignored or alternatively allowed, but corresponding download data may be discarded for a timeout period.While a system 3400 may be a WLAN compatible network, alternative embodiments may include any other suitable standard / protocol.Similarly, a system 3400 may include various interconnected networks, including piconetworks, PANs, LANs, WANs, both private and public, as well as the Internet.Embodiments may include methods, devices, and systems that, by operating a first wireless device, include receiving wireless messages from a wireless network and determining that a received wireless message is a disconnect message that instructs the first wireless device to end communications over the wireless network. A received disconnect message may be determined to be invalid in response to decrypting at least a portion of the received disconnect message and not finding a shared secret value previously established during a network join operation of the first wireless device. A received disconnect message may also be determined to be invalid in response to transmitting a query message addressed to at least one source address of the received disconnect message and receiving more response messages than expected. An invalid message may be ignored.Embodiments may include methods, apparatus, and systems including wireless circuitry configured to receive and transmit wireless messages according to at least one wireless standard and processor circuitry. Processor circuitry may be configured to determine that a received wireless message is a disconnect message that instructs the device to terminate communications over the wireless network. Processor circuitry may determine that the received disconnect message is not valid in response to decrypting at least a portion of the received disconnect message and not finding a shared secret value previously established during a network join operation of the first wireless device. Processor circuitry may also determine that the received disconnect message is not valid after transmitting a query message addressed to at least one source address of the received disconnect message and receiving more response messages than expected. An invalid disconnect message may be ignored.Embodiments may include methods, devices, and systems having a first wireless device configured to perform network join operations to enable joining wireless devices to access a wireless network, wherein the network join operation creates secure session data for the joining wireless devices. Secure session data may include at least device IDs of the joining wireless devices and shared secret values with the joining wireless devices. Authentication operations may be performed in response to receiving a network join request with a device-10 of the secure session data. Authentication operations may include decrypting the network join request and, in response to the decrypted network join message not including the shared secret value, ignoring the network join message. Authentication operations may also include performing a network join operation with a wireless device that issues the network join message, but discarding all wireless messages for transmission to the device ID for a predetermined timeout period.Methods, devices, and systems according to embodiments may include a deassociation or deauthentication frame compatible with at least one IEEE 802.11 wireless standard.Methods, apparatuses, and systems according to embodiments may include a query message selected from the group of: a block acknowledge request, a low power polling message, and a null data frame.Methods, devices, and systems according to embodiments may include, by operation of the first wireless device, performing a network join operation that includes exchanging messages with a second wireless device to create encryption operations for wireless messages on the wireless network and create at least the shared secret.Methods, devices, and systems according to embodiments may include a network join operation that includes an association operation compatible with at least one IEEE 802.11 wireless standard.Methods, devices, and systems according to embodiments may include a first wireless device that includes a first AP compatible with at least one IEEE 802.11 wireless standard and is part of a distributed system. By operating the first wireless device, at least the shared secret in an encrypted message may be transmitted to a second AP of the distributed system.Methods, devices, and systems according to embodiments may include a first wireless device that includes an AP compatible with at least one IEEE 802.11 wireless standard and is part of a distributed system (DS). By operation of the first wireless device, secure session data for a STA may be generated and stored during association with the STA. Secure session data may include at least one device address of the STA and a corresponding shared secret shared with the STA. Secure session data for at least one other STA associated with at least one other AP of the DS may be received and stored. In response to receiving a reassociation request having a device address of stored session data, the reassociation request may be decrypted and executed when the decrypted reassociation request comprises at least the corresponding shared secret. The reassociation request may be ignored if it does not include at least the corresponding shared secret.Methods, devices, and systems according to embodiments may include a first wireless device that includes an AP compatible with at least one IEEE 802.11 wireless standard and is part of a DS. By operating a first wireless device, secure session data for a STA may be generated and stored during association with the STA. Secure session data may include at least one device address of the STA and a corresponding shared secret with the STA. Secure session data may be received and stored for at least one other STA associated with at least one other AP of the DS. In response to receiving a reassociation request including a device address of stored session data, the reassociation request may be decrypted and a reassociation operation performed. Packets for transmission to the newly associated STA may be discarded for a predetermined timeout period if the decrypted reassociation request does not comprise at least the shared secret.Methods, devices, and systems according to embodiments may include wireless circuitry compatible with at least one IEEE 802.11 wireless standard, and a received disconnect message may include a deassociation or deauthentication message.Methods, devices, and systems according to embodiments may include wireless circuitry compatible with at least one IEEE 802.11 wireless standard, and a query message is selected from the group of: a block acknowledge request, a low power polling message, and a null data frame.Methods, apparatus, and systems according to embodiments may include processor circuitry configured to perform the network join operation. The network join operation may include exchanging messages with another wireless device to create wireless message encryption operations on the wireless network and creating at least one shared secret.Methods, devices, and systems according to embodiments may include processor circuitry configured to transmit at least the shared secret in an encrypted message to another device of the wireless network and receive shared secrets corresponding to other wireless devices of the wireless network.Methods, devices, and systems according to embodiments may include a wireless network compatible with at least one IEEE 802.11 wireless standard. Network join operations may include association operations. A device ID may include a MAC address. A network join message may include an association request or reassociation request.Methods, devices, and systems according to embodiments may include a second wireless device configured to transmit additional secure session data to a first wireless device. Additional secure session data may include device IDs and shared secret values of other joining wireless devices that have performed network joining operations with the second wireless device. A first wireless device may be configured to transmit its secure session data to the second wireless device and perform the authentication operations in response to receiving a network join request including a device ID of the secure session data or additional secure session data.Methods, devices, and systems according to embodiments may include a wireless network compatible with at least one IEEE 802.11 wireless standard. A first wireless device and second wireless devices may include access point devices of a same distributed system. Secure session data for the first wireless device may correspond to STAs associated with the first wireless device. Additional secure session data may correspond to STAs associated with the second wireless device.Methods, devices, and systems according to embodiments may include at least one joining wireless device configured to perform message verification operations in response to receiving a disconnect message instructing the joining wireless device to stop communications on the wireless network. Message verification operations may include decrypting the received disconnect message and, in response to the decrypted disconnect message comprising a shared secret value of the joining device, performing actions commanded by the disconnect message. In response to the decrypted disconnection message not including the joining secret value of the joining device, the disconnection message may be ignored.Methods, devices, and systems according to embodiments may include at least one joining wireless device configured to perform message verification operations in response to receiving a disconnect message instructing the joining wireless device to stop communications on the wireless network. Message verification operations may include transmitting a query message to a device address corresponding to the disconnect message and, in response to receiving more responses to the query message than expected, ignoring the disconnect message.It should be appreciated that throughout this specification, reference to "one embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Therefore, it is emphasized and should be appreciated that two or more references to "one embodiment" or "an alternative embodiment" in various parts of this specification do not necessarily all refer to the same embodiment. Further, the particular features, structures, or characteristics may be combined as appropriate in one or more embodiments of the invention.Similarly, it should be appreciated that in the foregoing description of embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure or description to obscure the disclosure and thus aid in understanding one or more of the various inventive aspects. This method of disclosure, however, should not be interpreted as reflecting an intention that the claims require more features than are expressly recited in each claim. Rather, inventive aspects lie in less than all features of a single preceding disclosed embodiment. Thus, the claims following the detailed description are hereby expressly incorporated into this detailed description, with each claim standing on its own as a separate embodiment of this invention.Although this invention has been described with reference to illustrative embodiments, this description is not to be construed in a limiting sense. Various modifications and combinations of the illustrative embodiments, as well as other embodiments of the invention, will become apparent to those skilled in the art upon reference to the specification. It is therefore intended that the appended claims include such modifications or embodiments.References included in the specificationThis list of documents cited by the applicant has been produced in an automated manner and is only included for the better information of the reader. The list is not part of the German patent application or utility model application. The DPMA does not take any adhesion for any faults or omissions.Patent Literature citedUS 63 / 543,406
[0001]
Claims
A method comprising: by operation of a first wireless device, receiving wireless messages from a wireless network, determining that a received wireless message is a disconnect message instructing the first wireless device to terminate communications over the wireless network, determining that the received disconnect message is not valid in response to decrypting at least a portion of the received disconnect message and not finding a shared secret value previously created during a network join operation of the first wireless device, or after transmitting a query message addressed to at least a source address of the received disconnect message, receiving more response messages than expected, and ignoring the received disconnect message if determined not valid.The method of claim 1, wherein the received disconnect message includes a deassociation or deauthentication frame compatible with at least one IEEE 802.11 wireless standard.The method of claim 2, wherein the query message is selected from the group of: a block acknowledge request, a low power polling message, and a null data frame.The method of claim 1, further comprising: by operation of the first wireless device, performing the network join operation comprising exchanging messages with a second wireless device to: create wireless message encryption operations on the wireless network and create at least the shared secret.The method of claim 4, wherein the network join operation includes an association operation compatible with at least one IEEE 802.11 wireless standard.The method of claim 4, further comprising: the first wireless device including a first access point device (AP) compatible with at least one IEEE 802.11 wireless standard and part of a distributed system; and by operation of the first wireless device, transmitting at least the shared secret in an encrypted message to a second AP of the distributed system.The method of claim 1, further comprising: the first wireless device including an access point device (AP) compatible with at least one IEEE 802.11 wireless standard and being part of a distributed system (DS); by operation of the first wireless device, generating and storing secure session data for a station device (STA) during association with the STA, the secure session data comprising at least one device address of the STA and a corresponding shared secret shared with the STA, receiving and storing secure session data for at least one other STA associated with at least one other AP of the DS in response to receiving a reassociation request, having a device address of stored session data, decrypting the reassociation request, and executing a Neuassoziierungsoperationsanfrage if the decrypted reassociation request includes at least the corresponding shared secret, and ignoring the reassociation request if the decrypted reassociation request does not include at least the corresponding shared secret.The method of claim 1, further comprising: the first wireless device including an access point device (AP) compatible with at least one IEEE 802.11 wireless standard and being part of a distributed system (DS); by operation of the first wireless device, generating and storing secure session data for a station device (STA) during association with the STA, the secure session data comprising at least one device address of the STA and a corresponding shared secret with the STA, receiving and storing secure session data for at least one other STA associated with at least one other AP of the DS in response to receiving a reassociation request, comprising a device address of stored session data, decrypting the reassociation request and performing a reassociation operation and discarding packets for transmission to the newly associated STA for a predetermined timeout period if the decrypted reassociation request does not comprise at least the shared secret.An apparatus, comprising: wireless circuitry configured to receive and transmit wireless messages according to at least one wireless standard; and processor circuitry configured to: determine that a received wireless message is a disconnect message instructing the apparatus to end communications over the wireless network, determine that the received disconnect message is not valid in response to decrypting at least a portion of the received disconnect message and not finding a shared secret value previously established during a network join operation of the first wireless device, or after transmitting a query message addressed to at least one source address of the received disconnect message, receive more response messages than expected, and ignore the received disconnect message if determined not valid.The apparatus of claim 9, wherein: the wireless circuits are compatible with at least one IEEE 802.11 wireless standard; and the received disconnect message includes a deassociation or deauthentication message.The apparatus of claim 9, wherein: the wireless circuits are compatible with at least one IEEE 802.11 wireless standard; and the query message is selected from the group of: a block acknowledge request, a low power polling message, and a null data frame.The apparatus of claim 9, wherein: the processor circuitry is further configured to perform the network join operation comprising: exchanging messages with another wireless device to create encryption operations for wireless messages on the wireless network, and creating at least the shared secret.The apparatus of claim 12, wherein: the wireless circuits are compatible with at least one IEEE 802.11 wireless standard; and the network join operation includes an associate operation.The apparatus of claim 9, wherein: the processor circuitry is further configured to: transmit at least the shared secret in an encrypted message to another device of the wireless network; and receive shared secrets corresponding to other wireless devices of the wireless network.A system comprising: a first wireless device configured to: perform network join operations to enable joining wireless devices to access a wireless network, the network join operation creating secure session data for the joining wireless devices, comprising at least: device identification values (IDs) of the joining wireless devices and common secret values with the joining wireless devices, perform authentication operations in response to receiving a network join request with a device ID of the secure session data, the authentication operations comprising: decrypting the network join request in response to the decrypted network join message not comprising the common secret value, Ignore the network join message or perform a network join operation with a wireless device issuing the network join message, but discard all wireless messages for transmission to the device ID for a predetermined timeout period.The system of claim 15, wherein: the wireless network is compatible with at least one IEEE 802.11 wireless standard; the network join operations include association operations; the device ID includes a media access control (MAC) address; and the network join message includes an association request or reassociation request.The system of claim 15, further comprising: a second wireless device configured to transmit additional secure session data to the first wireless device, wherein the additional secure session data includes device IDs and shared secret values of other joining wireless devices that have performed network joining operations with the second wireless device; and wherein the first wireless device is further configured to transmit its secure session data to the second wireless device and perform the authentication operations in response to receiving a network joining request with a device ID of the secure session data or additional secure session data.The system of claim 17, wherein: the wireless network is compatible with at least one IEEE 802.11 wireless standard; the first wireless device and second wireless devices include access point devices of a same distributed system; the secure session data for the first wireless device corresponds to station devices (STAs) associated with the first wireless device; and the additional secure session data corresponds to STAs associated with the second wireless device.The system of claim 15, further comprising: at least one joining wireless device configured to perform messaging operations in response to receiving a disconnect message instructing the joining wireless device to stop communications on the wireless network, the messaging operations comprising: decrypting the received disconnect message, in response to the decrypted disconnect message comprising a common secret value of the joining device, performing actions instructed by the disconnect message, and in response to the decrypted disconnect message not comprising the common secret value of the joining device, ignoring the disconnect message.The system of claim 17, further comprising: at least one joining wireless device configured to perform message verification operations in response to receiving a disconnect message instructing the joining wireless device to stop communications on the wireless network, the message verification operations comprising: transmitting a poll message to a device address corresponding to the disconnect message in response to receiving more responses to the poll message than expected, ignoring the disconnect message.