OBFUSCATION IN PRIVACY BEACON
Techniques are disclosed for obfuscation in a privacy beacon. An example method includes the first device receiving, from a second communication device, a beacon frame comprising a medium access control (MAC) header and an encrypted beacon frame field, the MAC header comprising an obfuscated timing synchronization field (TSF). The first device can select a key for de-obfuscating the TSF based at least in part on information associated with the beacon frame. The first device can de-obfuscate the TSF based at least in part on the key. The first device can decrypt the encrypted beacon frame field of the beacon frame based at least in part on information associated with the de-obfuscated TSF.
Latest Apple Patents:
This application is claims the benefit of U.S. Provisional Application No. 63/396,221, filed on Aug. 8, 2022, which is incorporated by reference.
BACKGROUNDA wireless network is a communication network that enables computing devices to communicate through radio transmissions and receptions between network nodes. These wireless networks permit users with greater mobility within the home and office environments by untethering their computing device from wired communication.
In the following description, various embodiments will be described. For purposes of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the embodiments. However, it will also be apparent to one skilled in the art that the embodiments may be practiced without the specific details. Furthermore, well-known features may be omitted or simplified in order not to obscure the embodiment being described.
In a wireless communication network, a frame can be a unit of data that can be transmitted between nodes. The frame can include the information useful to transmit data from one network node to another, including addressing information and protocol control information. A frame can include a header, a payload, and a trailer. Each of the header, payload, trailer can be configured to convey particular information. For example, a medium access control (MAC) header can be an ethernet header that includes data fields that can be added to a beginning of a network data packet to convert the packet into a frame to be transmitted. The MAC header can include a transmission protocol version, a frame type, a frame subtype, and a frame control flag. Under IEEE 802.11, only the payload of the frame can be encrypted, and therefore and header and trailer remain unencrypted.
A timing synchronization function (TSF) is specified in IEEE 802.11 and provides a mechanism for synchronizing the timers of each device in a basic service set (BSS). The timing synchronization can be achieved by computing devices that periodically exchange timing information through beacon frames. The beacon frame can be transmitted after a target beacon transmission time (TBTT). If, however, a communication channel is busy, reception of the beacon frame may be delayed. As the TSF value in the beacon frame can be time dependent, the delay can cause a change in the TSF value. Under current standards, if a value changes based on a time passing, the entire beacon frame can be encrypted to guard the changed value. Therefore, once the encrypted beacon frame is received, the frame can be decrypted. This decryption process can further add to the delay and can result in synchronization issues
Embodiments herein address the above referenced issues by providing a separate encryption process for the TSF value. The value in the TSF field can be encrypted by applying an offset to the TSF field. A device can then separately encrypt the beacon frame contents without encrypting the TSF as the offset has already been applied. The device can transmit the beacon frame to another device and even if the TSF field changes, the TSF field does not need to be encrypted as the offset has been applied.
As described above, the embodiments herein can calculate a single offset for all fields using a single function. In particular, the function can calculate one bit-stream, and then the device can allocate bits from the stream over specific fields to be obfuscated. The bit-stream can have dedicated bits for specific fields. For example, bit 0 of the bit-stream can be dedicated to a first bit of the MAC header. The device can determine how long of a bit-stream to generate based on the fields that can be obfuscated. To obfuscate a field, the device can take the original value and use an XOR function to perform an “exclusive or” with an offset value to calculate the over the air value. An example single function to calculate the offset bit stream can be as follows: Truncatedoffsetlength(SHA-256(LinkID, “Protection_Offset”, Of Key, OF_Salt_ST_STA_LT) LinkID can be the Link ID in which the beacon in transmitted. “Protection_Offset” can be a long plain text. OF-Key can be the key to protect the offset, which can be changed periodically. OF-Salt can be a number that can be changed periodically. There can be two salt values, a long-term value and a short-term value.
At 502, a device can receive a data payload from an application or the internet. The data payload can be included in a physical layer protocol data unit (PPDU) transmission. In response to receiving the data payload, the device can assign the payload a sequence number (SN) and a packet number (PN).
At 504, the device can encrypt the data payload.
At 506, the device can obfuscate and encrypt the MAC header and aggregate control (A-control) fields. In some instances, step 506 can occur at the next transmission opportunity (TXOP) time that occurs after encrypting the payload (step 504).
At 508, the device can transmit the data to a receiving device. For example, the device can be a transmitting device such as an access point and the receiving device can be a station that connects to a wireless local area network provided by the access point.
At 604, the device can parse the MAC header's obfuscated fields of a MAC protocol data unit (MPDU) to detect the size of the payload. The device can also use the +HTC field to determine the MAC header size. These values can be used later to assist in decryption of the payload, for example, to determine the size of a scrambler seed. The device can further use the over the air traffic identifier (OTA TID) and address field values of a received MAC protocol data unit to prepare a block acknowledgment frame and send the block acknowledgment a short interframe space (SIFS) after the PPDU. The device can further determine MD/end of service period (EOSP)/power management (PM). In some embodiments, step 604 can be a one-time operation regardless of the number of MAC protocol data units.
At 606, the device can decrypt the payload. In this step, the device can de-obfuscate addresses, packet numbers and sequence numbers for the additional authentication data (AAD) used for the payload decryption. The device can perform step 606 for each MAC protocol data unit that can be received at step 602. Upon decrypting the payload, the device can reorder the decrypted frames using a buffer. The device can then transmit the reordered frames to an application or the internet.
For the second alternative 704, the protocol version, type, subtype, duration/ID and frame check sequence (FCS) fields can be transmitted clear over the air. The first through fourth address fields, the traffic identifier (TID) field, and the sequence number (SN) fields can be obfuscated by applying the same offset value to each of the fields. The packet number, and aggregated MAC service data unit (A-MSDU) present, power management, more data, end of service period (EOSP) +HTC, and HT control fields can be encrypted. The retry field can be either set to zero of transmitted clear, or in some embodiment, handled as MD, EOSP or +HTC fields.
However, using seven bits results in only one hundred and twenty-seven variations. Therefore, a malicious attacker can discover the scrambler seed through brute force. To increase the number of bits, the herein described embodiments suggest using the reserve service bits 206 in addition to using the scrambler initialization bits 204. By using the reserve service bits 206, the scrambler seed can be extended to 2 octets, and this increases the number of possible variations increases to more than one hundred and twenty-seven possibilities.
To resolve this, the first device 1402 can be configured to include device specific keys for each of the other devices. Therefore, the first device can obfuscate a message with a device specific key that only the intended recipient can de-obfuscate. Therefore, upon receipt of a message, the other device (e.g, the second device 1404, the third device 1406, or the fourth device 1408) can attempt to descramble the message using the device's DL SU key. If the payload matches with the FCS, the STA can receive the frame. If the payload does not match the FCS, the other device can discard the message. This ensures that DL transmissions may be received by the correct device. The group frames may have a separate key that for group addressed SU PPDU obfuscation. The same group offset value can be used for all the other device in a BSS.
At 2404, the device can encrypt the data payload.
At 2406, the device can add obfuscate MAC fields to an each MDPU. In some instances, step 2406 can occur at the next transmission opportunity (TXOP) time that occurs after encrypting the payload (step 2404).
At 2408, the device can encrypt the encrypted header field for each MPDU and the fields to the MAC headers of the MPDUs.
At 2410, the device can transmit the data to a receiving device. For example, the device can be a transmitting device such as an access point and the receiving device can be a station that connects to a wireless local area network provided by the access point.
At 2504, the device can prepare a block acknowledgment for the device.
At 2506, the device can decrypt the encrypted MAC header field for the packet number.
At 2508, the device can reorder the MPDU frames using a buffer.
At 2510, the device can transmit the reordered frames to an application or internet.
At 2704, the device can create a random offset that is to be applied to the timing synchronization field of the beacon frame. For example, the device can apply the above referenced expression.
The current WLAN transmission rules define that at TSF value 0, the device has transmitted a Beacon. This causes a situation that every time the TSF value is multiple of Beacon interval value, the AP should transmit a Beacon frame, i.e., these TSF values are considered as TBTT times.
When the offset is added to the TSF value, then the TBTT may occur when TSF mod(Beacon Interval)=0. In this situation, the offset value selection may have limitations to ensure that beacons are not transmitted too frequently or too seldom. For instance, purely random offset may cause Beacon frame interval to be from 0 to two times the duration of the Beacon transmission interval. The maximum allowed beacon frame transmission interval may be limited to between 50% and 150% of the Beacon transmission interval.
If the beacon transmission interval does not change very often, the associated devices and scanning devices may easily detect the next Beacon transmission time. These devices may use of the same rule to determine the Beacon transmission time from the TSF as used for the legacy beacons that have no offset applied to OTA TSF field value.
If the TBTT may occur at any TSF value, then the transmitter may select the offset value more freely. In this approach, the transmitter and receivers may have a joint algorithm to calculate the TSF offset and the TBTT of the next Beacon frame.
At 2706, the device can apply the offset to the timing synchronization field. This can be based on a passing of the target beacon transmission time (TBTT).
At 2708, the device can transmit the beacon frame. For example, the device can transmit the beacon frame to another device in a basic service set (BSS).
The MAC header field can include a frame control subfield 2814, a duration subfield 2816, a first address subfield 2818, a second address subfield 2818, a third address subfield 2822, a sequence control subfield 2824, and HT control subfield 2826, a sequence control subfield 2828, and HT control 2830 subfield. The first address subfield 2818 can include a receiving device address, the second address subfield 2818 can include a random ID, and a third address subfield 2822 can include a checksum ID.
The beacon transmission interval should be changed at least when the AP/BSS identifier (Random ID or Checksum Id) in the Beacon frame is changed. This ensures that eavesdroppers cannot identify the AP with new identifier values from the TBTT interval.
For one or more embodiments, at least one of the components set forth in one or more of the preceding figures may be configured to perform one or more operations, techniques, processes, or methods as set forth in the example section below.
Any of the above-described examples may be combined with any other example (or combination of examples), unless explicitly stated otherwise. The foregoing description of one or more implementations provides illustration and description but is not intended to be exhaustive or to limit the scope of embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments.
Although specific embodiments have been described, various modifications, alterations, alternative constructions, and equivalents are also encompassed within the scope of the disclosure. Embodiments are not restricted to operation within certain specific data processing environments but are free to operate within a plurality of data processing environments. Additionally, although embodiments have been described using a particular series of transactions and steps, it should be apparent to those skilled in the art that the scope of the present disclosure is not limited to the described series of transactions and steps. Various features and aspects of the above-described embodiments may be used individually or jointly.
Further, while embodiments have been described using a particular combination of hardware and software, it should be recognized that other combinations of hardware and software are also within the scope of the present disclosure. Embodiments may be implemented only in hardware, or only in software, or using combinations thereof. The various processes described herein can be implemented on the same processor or different processors in any combination. Accordingly, where components or modules are described as being configured to perform certain operations, such configuration can be accomplished, e.g., by designing electronic circuits to perform the operation, by programming programmable electronic circuits (such as microprocessors) to perform the operation, or any combination thereof. Processes can communicate using a variety of techniques, including but not limited to conventional techniques for inter process communication, and different pairs of processes may use different techniques, or the same pair of processes may use different techniques at different times.
The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that additions, subtractions, deletions, and other modifications and changes may be made thereunto without departing from the broader spirit and scope as set forth in the claims. Thus, although specific disclosure embodiments have been described, these are not intended to be limiting. Various modifications and equivalents are within the scope of the following claims.
The use of the terms “a” and “an” and “the” and similar referents in the context of describing the disclosed embodiments (especially in the context of the following claims) are to be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. The terms “comprising,” “having,” “including,” and “containing” are to be construed as open-ended terms (i.e., meaning “including, but not limited to,”) unless otherwise noted. The term “connected” is to be construed as partly or wholly contained within, attached to, or joined together, even if there is something intervening. Recitation of ranges of values herein are merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, unless otherwise indicated herein, and each separate value is incorporated into the specification as if it were individually recited herein. All methods described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of any and all examples, or exemplary language (e.g., “such as”) provided herein, is intended merely to better illuminate embodiments and does not pose a limitation on the scope of the disclosure unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the disclosure.
Disjunctive language such as the phrase “at least one of X, Y, or Z,” unless specifically stated otherwise, is intended to be understood within the context as used in general to present that an item, term, etc., may be either X, Y, or Z, or any combination thereof (e.g., X, Y, and/or Z). Thus, such disjunctive language is not generally intended to, and should not, imply that certain embodiments require at least one of X, at least one of Y, or at least one of Z to each be present.
Preferred embodiments of this disclosure are described herein, including the best mode known for carrying out the disclosure. Variations of those preferred embodiments may become apparent to those of ordinary skill in the art upon reading the foregoing description. Those of ordinary skill should be able to employ such variations as appropriate, and the disclosure may be practiced otherwise than as specifically described herein. Accordingly, this disclosure includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the disclosure unless otherwise indicated herein.
All references, including publications, patent applications, and patents, cited herein are hereby incorporated by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein.
In the foregoing specification, aspects of the disclosure are described with reference to specific embodiments thereof, but those skilled in the art will recognize that the disclosure is not limited thereto. Various features and aspects of the above-described disclosure may be used individually or jointly. Further, embodiments can be utilized in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of the specification. The specification and drawings are, accordingly, to be regarded as illustrative rather than restrictive.
It is well understood that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. In particular, personally identifiable information data should be managed and handled so as to minimize risks of unintentional or unauthorized access or use, and the nature of authorized use should be clearly indicated to users.
Claims
1. A method, comprising:
- by a first communication device: receiving, from a second communication device, a beacon frame comprising a medium access control (MAC) header and an encrypted beacon frame field, the MAC header comprising an obfuscated timing synchronization field (TSF); selecting a key for de-obfuscating the TSF based at least in part on information associated with the beacon frame; de-obfuscating the TSF based at least in part on the key; and decrypting the encrypted beacon frame field of the beacon frame based at least in part on information associated with the de-obfuscated TSF.
2. The method of claim 1, wherein the method further comprises:
- determining whether the beacon frame comprises a second communication device address;
- determining whether the first communication device is an intended recipient of the beacon frame based at least in part on whether the beacon frame comprises the second communication device address;
- determining whether to discard the beacon frame based at least in part on whether the second communication device is the intended recipient of the beacon frame; and
- determining whether to decrypt the encrypted beacon frame field based at least in part on determining whether to discard the beacon frame.
3. The method of claim 1, wherein the method further comprises:
- determining a beacon frame type based at least in part on the information associated with the beacon frame, wherein the key is selected based at least in part on the beacon frame type.
4. The method of claim 1, wherein the method further comprises:
- identifying the second communication device based at least in part on information associated with the beacon frame, wherein the key is selected based at least in part on an identity of the second communication device.
5. The method of claim 1, wherein the method further comprises:
- determining a size of the encrypted beacon frame field based at least in part on information associated with the beacon frame; and
- determining a size of the MAC header based at least on information associated with the beacon frame, wherein the encrypted beacon frame field is decrypted based at least in part on the size of the encrypted beacon frame field and a size of the MAC header.
6. The method of claim 1, wherein the method further comprises:
- generating an acknowledgement of receipt of the beacon frame based at least in part on information associated with the beacon frame; and
- transmitting the acknowledgment to the second communication device.
7. The method of claim 1, wherein the obfuscated TSF is obfuscated based on an offset associated with the TSF.
8. A first communication device, comprising:
- one or more processors; and
- one or more computer-readable media having stored thereon a sequence of instructions which, when executed, cause the one or more processors to: receive, from a second communication device, a beacon frame comprising a medium access control (MAC) header and an encrypted beacon frame field, the MAC header comprising an obfuscated timing synchronization field (TSF); select a key for de-obfuscating the TSF based at least in part on information associated with the beacon frame; de-obfuscate the TSF based at least in part on the key; and decrypt the encrypted beacon frame field of the beacon frame based at least in part on information associated with the de-obfuscated TSF.
9. The first communication device of claim 8, wherein the instructions which, when executed, further cause the one or more processors to:
- determine whether the beacon frame comprises a second communication device address;
- determine whether the first communication device is an intended recipient of the beacon frame based at least in part on whether the beacon frame comprises the second communication device address;
- determine whether to discard the beacon frame based at least in part on whether the second communication device is the intended recipient of the beacon frame; and
- determine whether to decrypt the encrypted beacon frame field based at least in part on determining whether to discard the beacon frame.
10. The first communication device of claim 8, wherein the instructions which, when executed, further cause the one or more processors to:
- determine a beacon frame type based at least in part on the information associated with the beacon frame, wherein the key is selected based at least in part on the beacon frame type.
11. The first communication device of claim 8, wherein the instructions which, when executed, further cause the one or more processors to:
- identify the second communication device based at least in part on information associated with the beacon frame, wherein the key is selected based at least in part on an identity of the second communication device.
12. The first communication device of claim 8, wherein the instructions which, when executed, further cause the one or more processors to:
- determine a size of the encrypted beacon frame field based at least in part on information from the beacon frame; and
- determine a size of the MAC header based at least on information from the beacon frame, wherein the encrypted beacon frame field is decrypted based at least in part on the size of the encrypted beacon frame field and a size of the MAC header.
13. The first communication device of claim 8, wherein the instructions which, when executed, further cause the one or more processors to:
- generate an acknowledgement of receipt of the beacon frame based at least in part on information from the beacon frame; and
- transmit the acknowledgment to the second communication device.
14. The first communication device of claim 8, wherein the obfuscated TSF is obfuscated based on an offset associated with the TSF.
15. One or more computer-readable media having stored thereon a sequence of instructions that, when executed, cause the one or more processors to:
- receive, from a second communication device, a beacon frame comprising a medium access control (MAC) header and an encrypted beacon frame field, the MAC header comprising an obfuscated timing synchronization field (TSF);
- select a key for de-obfuscating the TSF based at least in part on information associated with the beacon frame;
- de-obfuscate the TSF based at least in part on the key; and
- decrypt the encrypted beacon frame field of the beacon frame based at least in part on information associated with the de-obfuscated TSF.
16. The one or more computer-readable media of claim 15, wherein the instructions which, when executed, further cause the one or more processors to:
- determine whether the beacon frame comprises a second communication device address;
- determine whether the first communication device is an intended recipient of the beacon frame based at least in part on whether the beacon frame comprises the second communication device address;
- determine whether to discard the beacon frame based at least in part on whether the second communication device is the intended recipient of the beacon frame; and
- determine whether to decrypt the encrypted beacon frame field based at least in part on determining whether to discard the beacon frame.
17. The one or more computer-readable media of claim 15, wherein the instructions which, when executed, further cause the one or more processors to:
- determine a beacon frame type based at least in part on the information associated with the beacon frame, wherein the key is selected based at least in part on the beacon frame type.
18. The one or more computer-readable media of claim 15, wherein the instructions which, when executed, further cause the one or more processors to:
- identify the second communication device based at least in part on information associated with the beacon frame, wherein the key is selected based at least in part on an identity of the second communication device.
19. The one or more computer-readable media of claim 15, wherein the instructions which, when executed, further cause the one or more processors to:
- determine a size of the encrypted beacon frame field based at least in part on information from the beacon frame; and
- determine a size of the MAC header based at least on information from the beacon frame, wherein the encrypted beacon frame field is decrypted based at least in part on the size of the encrypted beacon frame field and a size of the MAC header.
20. The one or more computer-readable media of claim 15, wherein the instructions which, when executed, further cause the one or more processors to:
- generate an acknowledgement of receipt of the beacon frame based at least in part on information from the beacon frame; and
- transmit the acknowledgment to the second communication device.
Type: Application
Filed: Aug 8, 2023
Publication Date: Feb 8, 2024
Applicant: Apple Inc. (Cupertino, CA)
Inventors: Jarkko L. Kneckt (Los Gatos, CA), Debashis Dash (San Jose, CA), Elliot S. Briggs (Carmel, CA), Nisan Reuven (Rehovot), Qi Wang (Sunnyvale, CA), Sidharth R. Thakur (San Jose, CA), Su Khiong Yong (Palo Alto, CA), Yong Liu (Campbell, CA), Tianyu Wu (Monterey, CA)
Application Number: 18/231,566