MAC header protection using pre-existing keys

Abstract

The invention relates to MAC header protection using pre-existing keys. Technical solutions relate to MAC address protection for frame integrity verification. A sender device may calculate a first key for a subject of a frame and a second key for a header of the frame using a temporary key (TK) programmed in hardware, the second key being different from the first key. The sender may encrypt the subject of the frame at a machine access control (MAC) layer using the first key, and encrypt the header of the frame at the MAC layer using the second key. The sender may compute a first MIC for an encrypted frame using the first key and compute a second MIC for content of the header at the MAC layer using the second key. The sender may transmit the frame having the first MIC and the second MIC to a receiver configured to determine an integrity of the header of the frame based on the second MIC.

Description

[0001] Cross-references to related patent applications

[0002] This application claims the benefit of and priority to U.S. Provisional Application No. 63 / 601,438, filed on November 21, 2023, U.S. Provisional Application No. 63 / 558,838, filed on February 28, 2024, and U.S. Provisional Application No. 63 / 563,092, filed on August 3, 2024, all of which are incorporated herein by reference in their entirety. Technical Field

[0003] The present disclosure generally relates to systems and methods for network traffic protection, including, for example, protection of MAC headers. Background Art

[0004] When exchanging network communications, network devices may use media access control (MAC) addresses to identify or distinguish devices participating in the communication. In various network communications, devices may use MAC addresses to route data to their desired destinations. Summary of the invention

[0005] The technical solution provided herein relates to providing security and integrity for the machine access control (MAC) header in the wireless communication frame. In wireless communication, the MAC header may be subject to tampering or unauthorized access by an attacker, who may intercept the network packet and change the MAC header data. The technical solution uses a hardware-programmed temporary key (TK) to derive separate keys for the body and header of the communication frame at the MAC layer, thereby improving the network packet integrity in a computationally efficient manner. For example, in a scenario where a wireless device exchanges sensitive information over a network, the MAC header data of any intercepted network packet may be manipulated to obtain unauthorized access to the system. The technical solution provides a computationally efficient and secure technique to protect the MAC header using existing systems and network infrastructure, thereby mitigating the risk of unauthorized access or data manipulation without increasing design complexity.

[0006] One aspect of the technical solution relates to a system. The system may include one or more processors coupled to a memory. The one or more processors may be configured to calculate a first key for the body of a frame and a second key for a header of a frame using a temporary key (TK) programmed in hardware, the second key being different from the first key. The one or more processors may be configured to encrypt the body of the frame at a machine access control (MAC) layer using the first key, and encrypt the header of the frame at the MAC layer using the second key. The one or more processors may be configured to calculate a first message integrity code (MIC) of the encrypted frame using the first key, and calculate a second MIC of the content of the header of the frame at the MAC layer using the second key. The one or more processors may be configured to transmit the frame with the first MIC and the second MIC to a receiver, the receiver being configured to determine the integrity of the header of the frame based at least on the second MIC.

[0007] The one or more processors may be configured to generate a combined MIC from the first MIC and the second MIC. The one or more processors may be configured to transmit the combined MIC to the recipient to determine the integrity of the frame. The combined MIC may be generated using one of: a concatenation of the first MIC and the second MIC, a bitwise exclusive OR (XOR) calculation applied to the first MIC and the second MIC, or any reversible calculation applied to the first MIC and the second MIC.

[0008] The one or more processors may be configured to calculate the first key using a hash-based message authentication code (HMAC) operation with a first input of the TK and a first fixed pattern. The one or more processors may be configured to calculate the second key using the HMAC operation with a second input of the TK and a second fixed pattern. The first fixed pattern may include a packet number (PN) of a network packet of the frame, and the second fixed pattern includes one or more characters of the body. The encryption of the body of the frame at the MAC layer using the first key may be performed simultaneously with the encryption of the header of the frame at the MAC layer using the second key.

[0009] The frame may correspond to a first network packet among a plurality of network packets. The first network packet may include a first packet number in the header of the frame. The one or more processors may be configured to determine to resend the first network packet as a second network packet having a second packet number in a second header of a second frame of the second network packet. The second packet number may be different from the first packet number. The one or more processors may be configured to calculate a first key for a second body of the second frame of the second network packet and a second key for the second header of the second frame using the TK. The first key of the first network packet may be different from the first key of the second network packet.

[0010] The first key for the second body of the second frame of the second network packet may be the same as the first key for the body of the frame of the first network packet. The one or more processors may be configured to identify one or more frames to be encrypted at the MAC layer for wireless communication. The one or more processors may be configured to encrypt the second frame of the second network packet at the MAC layer using the first key for the second body and the second key for the second header.

[0011] The one or more processors may be configured to determine a pairwise master key (PMK) during an exchange over a wireless network between a device including the one or more processors and a recipient. The one or more processors may be configured to generate the temporary key (TK) using the PMK. The recipient may be configured to determine the integrity of the header based on verification of the integrity of the header using the second MIC before decrypting the frame.

[0012] The one or more processors may be configured to include the second MIC in the header of the frame and transmit the frame with the second MIC included in the header of the frame. The one or more processors may be configured to calculate at least one of the first key or the second key using an Advanced Encryption Standard (AES) algorithm and calculate at least one of the first MIC or the second MIC using at least one of a Cipher Block Chaining-MAC Protocol (CCMP) or a Galois / Counter Mode Protocol (GCMP). The receiver may be configured to verify the integrity of the header of the frame using the second MIC before processing the body of the frame.

[0013] An aspect of the technical solution relates to a method. The method may be a method for providing protection for a machine access control (MAC) header of a frame. The method may include identifying, by one or more processors, a temporary key (TK) programmed in hardware to encrypt a frame at a machine access control (MAC) layer for wireless communication. The method may include calculating, by the one or more processors, a first key for encrypting a body of a frame and a second key for encrypting a header of the frame using the TK, the second key being different from the first key. The method may include identifying, by the one or more processors, one or more frames to be encrypted at the MAC layer for wireless communication. The method may include encrypting, by the one or more processors, the body of the one or more frames at the MAC layer using the first key, and encrypting the header of the one or more frames at the MAC layer using the second key.

[0014] The method may include calculating the first key using a hash-based message authentication code (HMAC) operation with a first input of the TK and a first fixed pattern. The method may include calculating the second key using the HMAC operation with a second input of the TK and a second fixed pattern. The first fixed pattern may include a packet number (PN) of a network packet of the frame, and the second fixed pattern includes one or more characters of the body.

[0015] The frame may correspond to a first network packet among a plurality of network packets, the first network packet including a first packet number in the header of the frame. The method may include determining, by the one or more processors, that the first network packet is to be resent as a second network packet, the second network packet having a second packet number in a second header of a second frame of the second network packet. The second packet number may be different from the first packet number. The method may include calculating, by the one or more processors, a first key for a second body of the second frame of the second network packet and a second key for the second header of the second frame using the TK. The first key of the first network packet may be different from the first key of the second network packet. The first key for the second body of the second frame of the second network packet may be the same as the first key for the body of the frame of the first network packet. The method may include identifying, by the one or more processors, one or more frames to be encrypted at the MAC layer for wireless communication. The method may include encrypting, by the one or more processors, the second frame of the second network packet at the MAC layer using the first key of the second body and the second key for the second header.

[0016] The method may include calculating the first key for the body using an Advanced Encryption Standard (AES) operation with a first input of the TK and a first fixed pattern, and calculating the second key for the header of the frame using the same AES operation with a second input of the TK and a second fixed pattern. The method may include calculating the second key for the header using the AES operation with a first input of the TK and a first fixed pattern, and using the TK as the first key for the body of the frame.

[0017] The encryption of the one or more frames may include applying a Cipher-Based Message Authentication Code (CMAC) or Galois / Counter Code (GMAC) technique in conjunction with Advanced Encryption Standard (AES) encryption. The method may include selecting between the CMAC and GMAC techniques based on at least one of a security setting for the wireless communication or a condition of a network used for the wireless communication. The method may include generating an initialization vector (IV) for encryption based on parameters of the frame and using the IV to encrypt the body of the frame.

[0018] One aspect of the technical solution relates to a system. The system may include one or more processors coupled to a memory and configured to identify a temporary key (TK) programmed in hardware to encrypt a frame at a machine access control (MAC) layer for wireless communication. The one or more processors may be configured to use the TK to calculate a first key for encrypting the body of a frame and a second key for encrypting a header of the frame, the second key being different from the first key. The one or more processors may be configured to identify one or more frames to be encrypted at the MAC layer for wireless communication. The one or more processors may be configured to encrypt the body of the one or more frames at the MAC layer using the first key, and encrypt the header of the one or more frames at the MAC layer using the second key. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] These and other aspects and features of the present embodiments will become apparent to those of ordinary skill in the art when the following description of specific embodiments is read in conjunction with the accompanying drawings.

[0020] Figure 1A is a block diagram depicting a network environment including one or more access points in communication with one or more devices or stations in accordance with some embodiments.

[0021] Figure 1B and 1C is a block diagram depicting a computing device used in conjunction with the methods and systems described herein, according to some embodiments.

[0022] Figure 2 is an example block diagram of a system for providing MAC header protection using pre-existing encryption keys according to an embodiment of the present solution.

[0023] Figure 3 is an example flow chart for MAC header protection according to an embodiment of the present solution.

[0024] Figure 4 is an example of another flow chart for MAC header protection according to an embodiment of the present solution.

[0025] Figure 5 is an example of a flow chart for providing MAC header protection according to an embodiment of the present solution.

[0026] Figure 6 is an example of a frame and a header according to an embodiment of the present solution.

[0027] Figure 7 is an example flow chart of a method for providing MAC header protection using pre-existing keys. DETAILED DESCRIPTION

[0028] The present embodiment will now be described in detail with reference to the accompanying drawings, which are provided as illustrative examples of the embodiments to enable those skilled in the art to practice the embodiments and alternatives obvious to those skilled in the art. The following figures and examples are not intended to limit the scope of the present embodiment to a single embodiment, but other embodiments are feasible by the interchange of some or all of the elements described or illustrated or elements obvious to those skilled in the art. Certain elements of the present embodiment may be partially or completely implemented using known components, only the parts necessary for the understanding of the present embodiment in such known components will be described, and the detailed description of other parts of such known components will be omitted to avoid confusing the present embodiment. The embodiments described in the context in which they are described should not be limited to the embodiments. For example, as will be apparent to those skilled in the art, embodiments described as implemented in software should not be limited to such implementations, but they may include implementations implemented in hardware or a combination of software and hardware, and vice versa, unless otherwise specified herein. In this specification, embodiments showing a single component should not be considered as limiting; on the contrary, the present disclosure is intended to cover other embodiments including multiple identical components, and vice versa, unless otherwise explicitly stated herein. Furthermore, applicant does not intend to assign uncommon or special meanings to any term in the specification or claims unless explicitly so stated.In addition, the present embodiments encompass present and future known equivalents to the known components mentioned herein by way of illustration.

[0029] The following IEEE standards (including any draft versions of such standards) are hereby incorporated by reference in their entirety and made a part of this disclosure for all purposes: Wi-Fi Alliance standards and IEEE 802.11 standards, including but not limited to IEEE 802.11a TM 、IEEE 802.11b TM 、IEEE 802.11g TM 、IEEE P802.11n TM ;IEEE P802.11ac TM ; and IEEE P802.11be TM Draft version D3.0 standard. Although the present disclosure may refer to aspects of these standards, the present disclosure is in no way limited to these standards.

[0030] For the purpose of reading the description of the various embodiments below, the following description of the sections of the specification and their corresponding contents may be helpful:

[0031] - Section A describes a network environment and a computing environment that can be used to practice the embodiments described herein;

[0032] - Section B describes MAC header protection using pre-existing keys.

[0033] A. Computing and Network Environment

[0034] Before discussing specific embodiments of the present solution, it may be helpful to describe aspects of an operating environment and associated system components (eg, hardware elements) in conjunction with the methods and systems described herein.

[0035] refer to Figure 1A , depicting an embodiment of a network environment. In brief overview, the network environment includes a wireless communication system that includes one or more access points (APs) or network devices 106, one or more stations (also referred to as STAs) or wireless communication devices 102, and network hardware components or network hardware 192. The wireless communication device or STA 102 may, for example, include a laptop computer, a tablet computer, a personal computer, and / or a cellular telephone device. Figure 1B and 1C The details of the embodiments of each station or wireless communication device 102 and AP or network device 106 (e.g., its internal hardware and software configuration) are described in more detail. In one embodiment, the network environment can be an ad hoc network environment, an infrastructure wireless network environment, a subnet environment, etc. The network device 106 or AP can be operably coupled to the network hardware 192 via a local area network connection.

[0036] The network device 106 or AP may include, for example, a Wi-Fi device that provides a WLAN, or a 5G base station for providing a cellular network. The network hardware 192, which may include routers, gateways, switches, bridges, modems, system controllers, appliances, etc., may provide a local area network connection for the communication system. Each of the network devices 106 or APs may have an associated antenna or antenna array to communicate with wireless communication devices in its area. The wireless communication device 102 may register with a specific network device 106 or AP to receive services from the communication system (e.g., via SU-MIMO or MU-MIMO configuration). For direct connections (e.g., point-to-point communications), some wireless communication devices may communicate directly via allocated channels and communication protocols. Some of the wireless communication devices 102 may be mobile or relatively stationary relative to the network device 106 or AP.

[0037] In some embodiments, the network device 106 or AP includes a device or module (including a combination of hardware and software) that allows the wireless communication device 102 to connect to a wired network using wireless fidelity (Wi-Fi) or other standards. The network device 106 or AP may sometimes be referred to as a wireless access point (WAP). The network device 106 or AP may be implemented (e.g., configured, designed and / or constructed) for operation in a wireless local area network (WLAN). In some embodiments, the network device 106 or AP may be connected to a router (e.g., via a wired network) as a standalone device. In other embodiments, the network device 106 or AP may be a component of a router. The network device 106 or AP may provide multiple device access to the network. The network device 106 or AP may, for example, be connected to a wired Ethernet connection and use a radio frequency link to provide a wireless connection so that other devices 102 can utilize the wired connection. The network device 106 or AP may be implemented to support standards for sending and receiving data using one or more radio frequencies. Those standards and the frequencies they use may be defined by IEEE (e.g., IEEE 802.11 standards). The network device 106 or AP may be configured and / or used to support public Internet hotspots and / or to extend the Wi-Fi signal range of the network on the network.

[0038] In some embodiments, the access point or network device 106 may be used for a wireless network (e.g., IEEE 802.11, Bluetooth, ZigBee, any other type of radio frequency based network protocol and / or variants thereof) (e.g., in a home, in a car, or in a building). Each of the wireless communication devices 102 may include a built-in radio and / or be coupled to a radio. Such wireless communication devices 102 and / or access points or network devices 106 may operate in accordance with various aspects of the present disclosure presented herein to enhance performance, reduce cost and / or size, and / or enhance broadband applications. Each wireless communication device 102 may have the ability to act as a client node seeking access to resources (e.g., data and connections to networked nodes such as servers) via one or more access points or network devices 106.

[0039] The network connection may include any type and / or form of network, and may include any of the following: a point-to-point network, a broadcast network, a telecommunications network, a data communications network, a computer network. The network topology may be a bus, a star, or a ring network topology. The network may be any such network topology known to those of ordinary skill in the art that is capable of supporting the operations described herein. In some embodiments, different types of data may be transmitted via different protocols. In other embodiments, the same type of data may be transmitted via different protocols.

[0040] The communication device 102 and the access point or network device 106 may be deployed as and / or executed on any type and form of computing device, such as a computer, network device, or appliance capable of communicating over any type and form of network and performing the operations described herein. Figure 1B and 1C A block diagram of a computing device 100 is depicted that may be used to practice embodiments of a wireless communication device 102 or a network device 106. Figure 1B and 1C As shown in FIG. 1 , each computing device 100 includes a processor 121 (eg, a central processing unit) and a main memory unit 122. Figure 1B As shown in FIG. 1 , computing device 100 may include storage device 128, installation device 116, network interface 118, I / O controller 123, display devices 124a to 124n, keyboard 126, and pointing device 127 (e.g., mouse). Storage device 128 may include an operating system and / or software. Figure 1C As shown in , each computing device 100 may also include additional optional elements that communicate with the central processing unit or processor 121, such as a memory port 103, a bridge 170, one or more input / output devices 130a to 130n, and a cache memory 140.

[0041] The central processing unit or processor 121 is any logic circuitry that responds to and processes instructions fetched from the main memory unit 122. In many embodiments, the central processing unit or processor 121 is provided by a microprocessor unit, such as those manufactured by Intel Corporation of Santa Clara, California; by International Business Machines of White Plains, New York; or by Advanced Micro Devices of Sunnyvale, California. The computing device 100 may be based on any of these processors, or any other processor capable of operating as described herein.

[0042] The main memory unit 122 may be one or more memory chips capable of storing data and allowing any storage location to be directly accessed by the microprocessor or processor 121, such as any type or variation of static random access memory (SRAM), dynamic random access memory (DRAM), ferroelectric RAM (FRAM), NAND flash memory, NOR flash memory, and solid state drive (SSD). The main memory unit 122 may be based on any of the above-mentioned memory chips, or any other available memory chip capable of operating as described herein. Figure 1B In the embodiment shown in , processor 121 communicates with main memory unit 122 via system bus 150 (described in more detail below). Figure 1C An embodiment of the computing device 100 is depicted in which the processor communicates directly with the main memory unit 122 via the memory port 103. For example, in Figure 1C In the embodiment, the main memory unit 122 may be a DRDRAM.

[0043] Figure 1C An embodiment is depicted in which the main processor 121 communicates directly with the cache memory 140 via a secondary bus (sometimes referred to as a backside bus). In other embodiments, the main processor 121 communicates with the cache memory 140 using the system bus 150. The cache memory 140 typically has a faster response time than the main memory unit 122 and is provided by, for example, SRAM, BSRAM, or EDRAM. Figure 1C, the processor 121 communicates with various I / O devices 130 via a local system bus 150. Various buses may be used to connect the central processing unit or processor 121 to any of the I / O devices 130, such as a VESAVL bus, an ISA bus, an EISA bus, a Micro Channel Architecture (MCA) bus, a PCI bus, a PCI-X bus, a PCI-Express bus, or a NuBus. For embodiments in which the I / O device is a video display 124, the processor 121 may communicate with the display 124 using an Advanced Graphics Port (AGP). Figure 1C An embodiment of a computer or computer system 100 is depicted in which the main processor 121 can communicate directly with the I / O device 130b, such as via HYPERTRANSPORT, RAPIDIO, or INFINIBAND communication technology. Figure 1C Also depicted is an embodiment in which local busses and direct communications are mixed: processor 121 communicates with I / O device 130a using a local interconnect bus while communicating directly with I / O device 130b.

[0044] There may be a variety of I / O devices 130a to 130n in the computing device 100. Input devices include keyboards, mice, trackpads, trackballs, microphones, dials, touchpads, touch screens, and drawing tablets. Output devices include video displays, speakers, inkjet printers, laser printers, projectors, and thermal sublimation printers. Figure 1B , the I / O devices may be controlled by an I / O controller 123. The I / O controller may control one or more I / O devices, such as a keyboard 126 and a pointing device 127, such as a mouse or an optical pen. In addition, the I / O devices may also provide storage and / or installation media for the computing device 100. In yet other embodiments, the computing device 100 may provide a USB connection (not shown) to accept a handheld USB storage device, such as the USB flash drive series of devices manufactured by Twintech Industry, Inc. of Los Alamitos, California.

[0045] Reference again Figure 1B, the computing device 100 may support any suitable installation device 116, such as a disk drive, a CD-ROM drive, a CD-R / RW drive, a DVD-ROM drive, a flash drive, a tape drive of various formats, a USB device, a hard drive, a network interface, or any other device suitable for installing software and programs. The computing device 100 may further include a storage device, such as one or more hard drives or a redundant array of independent disks, for storing an operating system and other related software and for storing application software programs (e.g., any program or software 120 used to implement (e.g., configured and / or designed for) the systems and methods described herein). Optionally, any of the installation devices 116 may also be used as a storage device. In addition, the operating system and software may be run from a bootable medium.

[0046] In addition, the computing device 100 may include a network interface 118 to interface to a network through various connections, including but not limited to a standard telephone line, a LAN or WAN link (e.g., 802.11, T1, T3, 56kb, X.25, SNA, DECNET), a broadband connection (e.g., ISDN, Frame Relay, ATM, Gigabit Ethernet, Ethernet-over-SONET), a wireless connection, or some combination of any or all of the above. The connection may be established using various communication protocols (e.g., TCP / IP, IPX, SPX, NetBIOS, Ethernet, ARCNET, SONET, SDH, Fiber Distributed Data Interface (FDDI), RS232, IEEE 802.11, IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, IEEE 802.11n, IEEE802.11ac, IEEE 802.11ad, CDMA, GSM, WiMax, and direct asynchronous connection). In one embodiment, computing device 100 communicates with other computing devices 100' via any type and / or form of gateway or tunneling protocol, such as Secure Sockets Layer (SSL) or Transport Layer Security (TLS). Network interface 118 may include a built-in network adapter, a network interface card, a PCMCIA network card, a card bus network adapter, a wireless network adapter, a USB network adapter, a modem, or any other device suitable for interfacing computing device 100 to any type of network capable of communicating and performing the operations described herein.

[0047] In some embodiments, the computing device 100 may include or be connected to one or more display devices 124a to 124n. Thus, any of the I / O devices 130a to 130n and / or the I / O controller 123 may include any type and / or form of appropriate hardware, software, or combination of hardware and software to support, enable, or provide for connection and use of the display device(s) 124a to 124n by the computing device 100. For example, the computing device 100 may include any type and / or form of video adapter, video card, driver, and / or library to interface, communicate, connect, or otherwise use the display device(s) 124a to 124n. In one embodiment, the video adapter may include multiple connectors to interface to the display device(s) 124a to 124n. In other embodiments, the computing device 100 may include multiple video adapters, each of which is connected to the display device(s) 124a to 124n. In some embodiments, any portion of the operating system of the computing device 100 may be configured for use with the multiple display devices 124a to 124n. In further embodiments, the I / O device 130 may be a bridge between the system bus 150 and an external communication bus such as a USB bus, an Apple Desktop bus, an RS-232 serial connection, a SCSI bus, a FireWire bus, a FireWire 800 bus, an Ethernet bus, an AppleTalk bus, a Gigabit Ethernet bus, an Asynchronous Transfer Mode bus, a FibreChannel bus, a fiber optic bus, a Serial Attached Small Computer System Interface bus, a USB connection, or an HDMI bus.

[0048] Figure 1B and 1CA computing device 100 of the type depicted in the may operate under the control of an operating system that controls the scheduling of tasks and access to system resources. The computing device 100 may run any operating system, such as any version of the MICROSOFT WINDOWS operating system, different versions of the Unix and Linux operating systems, any version of the MAC OS for Macintosh computers, any embedded operating system, any real-time operating system, any open source operating system, any proprietary operating system, any operating system for mobile computing devices, or any other operating system capable of running on a computing device and performing the operations described herein. Typical operating systems include, but are not limited to, Android produced by Google Inc.; WINDOWS 7, 8 and 10 produced by Microsoft Corporation of Redmond, Washington; MAC OS produced by Apple Computer of Cupertino, California; WebOS produced by Research In Motion (RIM); OS / 2 produced by International Business Machines of Armonk, New York; and Linux, a free-to-use operating system released by Caldera, Inc. of Salt Lake City, Utah, or any type and / or form of Unix operating system and other operating systems.

[0049] The computer system or computing device 100 may be any workstation, phone, desktop computer, laptop or notebook computer, server, handheld computer, mobile phone or other portable telecommunication device, media playback device, gaming system, mobile computing device, or any other type and / or form of computing, telecommunication or media device capable of communication. In some embodiments, the computing device 100 may have a different processor, operating system, and input device consistent with the device. For example, in one embodiment, the computing device 100 is a smart phone, mobile device, tablet computer, or personal digital assistant. In addition, the computing device 100 may be any workstation, desktop computer, laptop or notebook computer, server, handheld computer, mobile phone, any other computer, or other form of computing or telecommunication device capable of communication and having sufficient processor power and memory capacity to perform the operations described herein.

[0050] Aspects of the operating environment and components described above will become apparent in the context of the systems and methods disclosed herein.

[0051] B. MAC header protection using a pre-existing key

[0052] When a data packet is retransmitted by a sender during a network communication, some header fields within the media access control (MAC) header of the data packet may be altered by a malicious actor. In some types of network communications, such as wireless local area network (WLAN) communications (e.g., Wireless Fidelity or Wi-Fi), the MAC header may contain unencrypted data. These unprotected header fields may be initially masked, but may be intercepted and altered upon retransmission of a transmission, allowing potential attacks on the system. This vulnerability opens the door to potential attacks on the system because an attacker may manipulate fields such as power management state and aggregation state. Cryptographic mechanisms such as the Counter Mode Cipher Block Chaining-MAC Protocol (CCMP) and the Galois / Counter Mode Protocol (GCMP) may be used to encrypt and calculate the integrity check value / message integrity code (ICV / MIC) of a frame. However, some of the MAC header fields remain unprotected and are vulnerable to attack.

[0053] To address this problem, a technical solution may use a pre-existing encryption key to generate or calculate a MIC on the MAC header, thereby capturing the original state of the MAC address when received by the receiving device for network packet integrity verification. In some instances, the calculated MIC may be integrated with the MIC calculated for the entire frame, thereby preserving existing security measures. This mechanism may be efficient because it may be employed multiple times on a given frame without introducing additional state or keys, thereby providing additional security without requiring additional computing resources.

[0054] Lack of protection for specific fields within the MAC header, such as the Power Management (PM) bit and the sequence number, may lead to network traffic security challenges. Lack of protection for these MAC header fields may lead to potential unauthorized modifications by an attacker, adversely affecting device performance and corrupting aggregate state. Using a set of alternative keys to address this security vulnerability may be undesirable as it may involve maintaining additional hardware (HW) and software (SW) state to support such keys. In addition, defined mechanisms will be used to maintain and manage the replay state of the MAC header, as well as the process of defining and deriving these keys and managing their rotation or change, all of which will add complexity beyond existing security measures.

[0055] The technical solution of the present disclosure is intended to extend and reuse existing mechanisms, thereby reusing existing key mechanisms for MAC header protection. This approach can minimize the HW and firmware (FW) state developed to provide protection for the MAC header, thereby leveraging existing replay checks to allow replay to be detected in the context of MAC header protection. CCMP and GCMP mechanisms can be used or extended to seamlessly integrate the MIC calculated for MAC header protection. This integration can occur without changing the format of the frame, eliminating the need for additional space. In the case where it is desired to encrypt the MAC header protection, the same key can be used, but the frame can carry supplementary encrypted data. In order to circumvent security issues, the technical solution utilizes an initialization vector (IV) (16 octets) using different packet numbers (PN) (6 octets). This comprehensive approach enables the solution to effectively address the challenges that arise in 11bn deployments.

[0056] Technical solutions can use a different set of keys. To perform replay checks independently of MAC header protection, header protection can utilize additional space / fields in the frame to carry header field information encrypted with the same key. UHR / 11bn may be relevant to Wi-Fi customers, allowing for higher levels of security at a lower cost.

[0057] These technical solutions maintain the same frame format without the need to introduce a specific MAC Header Protection (MHP) header. The number of unicast keys can remain unchanged. The coupling of the MHP header with the tag from the body encryption can be used to prevent potential attacks because the lack of coupling can cause the MHP header of one frame to be mixed with the body of another frame, potentially resulting in the loss of protection of the changed header fields. The same keys, metadata algorithms, and PNs can be used with MHP without the need to change the protocol, such as 4-way handshakes, while avoiding additional replay checks and corresponding transmission and reception states of the MHP keys. The Operational Channel Verification (OCV) function can help eliminate multi-channel man-in-the-middle (MITM) attacks. These solutions can bring minimal changes to the current protocol, supporting both CCMP and GCMP while reducing security vulnerabilities and aligning links with blocks using the same keys, which is a feature shared with CCMP and GCMP.

[0058] Figure 2An example system 200 for providing MAC header protection is illustrated. System 200 may include a sender device 202 communicating with a recipient device 204 via a communication link 206. Sender device 202 may include one or more key generators 208, a packet transmission manager (PTM) 220, a message integrity code (MIC) engine 240, a MIC combiner 250, and a coordinator 260. Keys 210 may include one or more temporary keys (TKs) 212, a body key 214, a header key 216, and a master key 218. MIC engine 240 may include, generate, process, or provide one or more frame MICs 242 and header MICs 244 for transmission with frame 230 to allow recipient device 204 to verify the integrity of the transmission. PTM 220 may include one or more encryption engines 222 for encrypting frame 230 using key 210. Each frame 230 may include at least a body 232 and a header 234 having one or more header parameters 236 (eg, data bits to be encrypted and protected). The MIC combiner 250 may include or generate one or more combined MICs 252 for communication with the recipient device 204.

[0059] Across the links 206, the recipient device 204 may include one or more coordinators 260 for establishing and exchanging network communications and one or more PTMs 220 for processing network packets, such as frames 230. The recipient device 204 may also include one or more MIC engines 242 that include or generate one or more expected frame MICs 272, expected header MICs 274, and expected combined MICs 276. The recipient device 204 may include one or more integrity check functions (ICFs) 270 that may check and verify the integrity of a frame 230 received by the recipient device 204 by comparing a frame MIC 242 of an incoming frame 230 with an expected frame MIC 272 generated by the MIC engine 242, comparing a header MIC 244 of an incoming frame 230 with an expected header MIC 274 generated by the MIC engine 242, or comparing a combined MIC 252 of an incoming frame 230 with an expected combined MIC 276.

[0060] The sender device 202 and the recipient device 204 (collectively referred to as devices 202 and 204) may each include any combination of hardware and software configured for network communications via a wired or wireless network. The sender device 202 and the recipient device 204 may each be or include any network device 106 (e.g., a Wi-Fi access point), a client device 102 (e.g., a computer or smartphone), or a node 192 (e.g., a router or gateway), or functionality provided by a cloud-based system. The sender device 202 and the recipient device 204 may include or utilize a computing system 100, and may include and utilize one or more processors (e.g., 121), which may be coupled to a memory (e.g., 122) and utilize instructions or software 120 stored in the memory to implement the functionality of the sender device 202 or the recipient device 204.

[0061] Link 206 may include any physical or logical connection that facilitates data transmission between devices 202 and 204. Link 206 may include various wired and wireless networks or communication technologies, including WLAN, Wi-Fi, cellular networks, and various forms of wired connections. For example, in a Wi-Fi network, link 206 may include radio wave signals transmitted between access points and client devices, thereby facilitating wireless data transmission. For example, communication link 206 may include radio frequency signals transmitted between base stations and mobile devices, thereby supporting voice and data communications over long distances. For example, link 206 may include or be part of an Ethernet or fiber optic connection network, which includes physical cables that transmit data packets between devices. The communication link serves as a medium for transmitting frames 230 (e.g., data or network packets).

[0062] Frame 230 (also referred to as a network packet) may include any discrete unit of data transmitted over a network (e.g., link 206). Each frame 230 may include a body 232 and a header 234, and may encapsulate payload data and control information for routing and processing network packets. For example, in a wireless communication system, frame 230 may include payload data (e.g., text, video, sensor readings, or any other data to be transmitted) in the body 232 portion, while the header 234 portion may include information such as a packet sequence number and addressing information. Frame 230 may be a frame of a link layer (e.g., MAC layer), an Internet layer or network layer, a transport layer, a session layer, a presentation layer, or an application layer in the Open Systems Interconnection (OSI) model or the TCP / IP model.

[0063] The body 232 of the frame 230 may include any data payload to be transmitted over the network (e.g., via the link 206). The body 232 may include various types of information, such as sensor readings, audio / video streams, textual contents of an email or document, or any application-specific data, depending on the application. The body 232 may include payload data regarding temperature readings from a sensor, data from an application running on a computing device, portions of an image or video, or any other information being transmitted. The body 232 may be encrypted using various encryption techniques, including, for example, the key 210, such as the body key 214.

[0064] The header 234 may be any portion of a frame 230 (e.g., a network packet) that includes control information for the frame, such as source and destination Internet Protocol addresses, protocol information, error detection codes, and other metadata. The header 234 may include parameters 236 for routing and processing any information or data (e.g., control signals or metadata) for the frame 230. The header 234 may include parameters 236, such as data bits for, indicating, or corresponding to a packet sequence number, source and destination addresses, frame control bits. The header 234 may be a header for the MAC layer. The header 234 may include information that provides context for the frame and facilitates devices on the network to accurately interpret and process the transmitted data. For example, the header 234 of a frame 230 in a Wi-Fi network may include information about the frame type, transmission rate, and frame duration.

[0065] Parameters 236 may include any value or indicator within header 234. Parameters 236 may include specific fields or attributes that are protected to facilitate data integrity during transmission. Parameters 236 may include packet numbers, frame control bits, and other header fields that are critical to network protocol operation. Protecting parameters 236 from tampering by third parties may prevent unauthorized modifications that may compromise the integrity of the transmitted data. For example, in a wireless communication system, parameters 236 (e.g., frame sequence numbers and frame types) may be protected to maintain the reliability of communications.

[0066] The keys 210 may include any type and form of encryption keys used to protect communications between the devices 202 and 204. The keys 210 may include any encryption keys used by the system, including a temporary key (TK) 212, a body key 214, a header key 216, and a master key 218. The TK 212 may be a temporary key implemented in the hardware of the system (e.g., a permanent storage device) and may be used by the devices 202 and 204 for various communication sessions. The body key 214 and the header key 216 may be used to encrypt at least a portion of the body 232 and header 234 of the frame 230 in its entirety or any portion thereof, as well as encryption with respect to any layer (e.g., a data link or MAC layer). The master key 218 may be used as a root key from which the TK may be derived during a handshake and negotiation between the devices 202 and 204.

[0067] Temporary key (TK) 212 may include any cryptographic key stored, programmed, or implemented in hardware. TK 212 may be generated or derived from master key 218 and may be used to protect the transmission of data between devices 202 and 204. For example, in a Wi-Fi network, a TK is generated during the authentication and key establishment process between a client device and an access point to facilitate confidentiality and integrity of data exchanged between devices for a period of time, such as a period of time after a handshake or session.

[0068] The body key 214 may include any encryption key used to encrypt the body 232 of the frame 230 for transmission of the frame (e.g., a network packet). The body key 214 may be derived from the TK 212, which may be stored in a storage device. The body key 214 may be used to protect the confidentiality of the payload data contained within the body of the frame. For example, in a wireless communication system, the body key 214 may be used to encrypt portions of text, images, video, sensor readings, or other sensitive information before transmission over the network.

[0069] Header key 216 may include any encryption key used to encrypt the header of a frame during transmission. Like body key 214, header key 216 may be derived from TK 212 and used to facilitate confidentiality and integrity of header information (e.g., parameters 236) within frame 230. For example, in a wireless network, header key 216 may be used to encrypt control information (e.g., packet sequence numbers and frame control bits) to prevent unauthorized access or manipulation of header data.

[0070] The master key 218 may include any encryption key used as a root key. A temporary key (TK) 212 may be derived from the master key. The master key 218 may be established during the initial establishment of a secure communication environment and may be used to generate TK 212 for subsequent communication sessions between two network devices. For example, in a wireless network, the master key 218 may be distributed during the authentication and key establishment process between devices, thereby providing a secure basis for generating TK 212 from the master key 218 used during data transmission.

[0071] The key generator 208 may include any combination of hardware and software for generating keys 210. The key generator 208 may include functionality to generate encryption keys 210 for protecting communications between devices. The key generator 208 combines hardware and software elements to produce keys 210, such as temporary keys (TK) 212, subject keys 214, header keys 216, and master keys 218. For example, in a wireless network, the key generator 208 may utilize an algorithm to derive the TK 212 from the master key 218 during a handshake or establishment of a secure connection between devices 202 and 204.

[0072] The key generator 208 may include functionality to calculate a body key 214 of the body of the frame 230 and a header key 216 of the header of the frame 230 using a temporary key (TK) 212 programmed in hardware. The header key 216 may be different from the body key 214. The key generator 208 may calculate the body key 214 or the header key 216 using a hash-based message authentication code (HMAC) operation with a first input of the TK 212 and a specific (e.g., first) fixed pattern. The fixed pattern may include any predetermined sequence of values ​​(e.g., parameters 236 or characters). The fixed pattern may be used to derive the header key 216 or the body key 214 for the encryption process. The key generator 208 may include functionality to calculate another key using an HMAC operation with a second input of the TK 212 and a second fixed pattern. The first fixed pattern may include a packet number (PN) of a header 234 of a network packet of the frame or any other content, and the second fixed pattern may include one or more characters of the body (e.g., content).

[0073] The key generator 208 may include functionality to calculate the body key 214 or the header key 216 using the Advanced Encryption Standard (AES) algorithm. The key generator 208 may include functionality to calculate the frame MIC 242 or the header MIC 244 using at least one of the Cipher Block Chaining-MAC Protocol (CCMP) or the Galois / Counter Mode Protocol (GCMP), or any other alternative protocol.

[0074] The key generator 208 may include functionality to handle the retransmitted frame 230 in order to protect the header 234. When retransmitting the frame 230, the key generator 208 may calculate the body key 214 for the second body 232 of the second frame 230 of the second network packet being retransmitted using the TK 212. The key generator 208 may calculate the header key 216 for the second header 234 of the second frame 230. The first header key 216 of the header 234 of the previous frame 230 may be different from the new or second header key 216 of the header 234 of the frame 230 being retransmitted.

[0075] The key generator 208 may utilize the packet number from the sequence to create a header key 216 that is unique for each of the frames 230 in the sequence of frames because each frame 230 may have a different packet number. The body key 214 for the second body 232 of the second frame 230 of the second network packet may be the same as the body key 214 for the body 232 of the previous (e.g., previously transmitted) frame 230. Since the key generator 208 may utilize the content of the retransmitted frame 230 (which may be the same as the previously transmitted frame 230), the body key 214 may be the same, while the header key 216 (e.g., based on a different packet number or other identifier of the packet) may be different for each retransmitted frame 230.

[0076] The key generator 218 may include functionality to determine a pairwise master key (PMK) 218 ​​during a negotiation or handshake between the devices. For example, the key generator 208 may include functionality to determine the PMK 218 during an exchange between the devices 202 and 204 over a wireless network. For example, the PMK 218 may be determined based on data, content, or control signals exchanged between the devices 202 and 204 during a sequence. The key generator 218 may use the PMK 218 to generate the TK 212. The TK 212 may be stored in hardware, such as a storage device (e.g., 128), from which the key generator 218 may retrieve the TK 212 for use in generating the body key 214 and the header key 216 based on the content of the body 232 and the header 234.

[0077] Packet transmission manager (PTM) 220 may include any combination of hardware and software for managing or controlling packet transmissions. PTM 220 may include one or more components or circuits for managing and implementing the transmission and reception of network packets (e.g., frames 230) between sender device 202 and receiver device 204. PTM 220 may include functionality to facilitate reliable and efficient transmission of data through a network. For example, in a wireless communication system, the PTM may coordinate the encryption and transmission of frames 230 between a sender device and a receiver device, employing encryption engine 222 to protect the data during transmission.

[0078] PTM 220 may include functionality to transmit a frame having a first MIC (e.g., frame MIC 242) and a second MIC (e.g., header MIC 244) to recipient device 204. Recipient device 204 may be configured to determine the integrity of header 234 of the frame based on at least the second MIC (e.g., header MIC 244), such as by using integrity check function 270 of recipient device 204. PTM 220 may be configured to transmit combined MIC 252 to recipient device 204 to determine the integrity of frame 230.

[0079] When transmitting a series of frames 230, the PTM 220 may resend a frame 230 that was not successfully transmitted in a previous attempt. In such an example, the frame 230 may include a parameter 236 of a packet number (PN) of the frame 230 that uniquely identifies the frame 230 from other frames 230 in the series (including the same frame 230 that was previously transmitted). Upon determining that the first network packet was not received, the PTM 220 may determine to resend the first network packet as a second network packet with a parameter 236 that uses a second packet number in a second header 234 of a second frame 230 of the second network packet, the second packet number being different from the first PN of the previous frame 230. Thus, even if the payloads of the two frames 230 are the same, the second packet number (e.g., parameter 236) of the resent frame 230 may be different from the first packet number (e.g., parameter 236) of the originally transmitted frame 230. Since each of the two frames 230 may have its header 234 with different PN parameters 236, the header MIC 244 of the two frames 230 will be different, allowing the ICF 270 of the receiver 204 to detect any tampered frame 230 because its expected header MIC 274 will not match the header MIC 244 received with the incoming frame 230.

[0080] For example, PTM 220 may utilize encryption engine 222 to encrypt each header 234 of transmitted frame 230 using header key 216. PTM 220 may utilize encryption engine 222 to encode a unique PN (e.g., parameter 236) of frame 230 for each header 234 of frame 230. PTM 220 may utilize MIC engine 240 to generate a header MIC 244 of header 234 for encryption of header 234. For example, PTM 220 may transmit header MIC 244 to recipient device 204 along with frame 230. In some examples, header MIC 244 may be included in header 234 of transmitted frame 230. Upon receiving frame 230, ICF 270 may utilize MIC engine 240 of recipient device 204 to generate expected frame MIC 272, expected header MIC 274, or expected combined MIC 276. If an attacker intercepts and tampers with the parameters 236 of the header 234 of the incoming frame 230, the header MIC 244 will not match the expected header MIC 274, and the ICF 270 will determine, based on the failed match, that the integrity of the incoming frame 230 has failed. In response to such a determination, the ICF 270 may send a message to the sender device 202 to notify the sender device 202 to resend the frame 230 again.

[0081] The encryption engine 222 may include any combination of hardware and software for performing encryption and decryption operations for data transmitted over a network. The encryption engine 222 may utilize an encryption algorithm, such as the Advanced Encryption Standard (AES), to facilitate confidentiality and integrity of the transmitted data. For example, in a wireless communication system, an encryption engine is employed to encrypt the body and header of a frame using a key 210 that may be derived from a temporary key (TK) 212, thereby protecting the data from unauthorized access or interception. The encryption engine 222 may encrypt the body 232 of the frame at the MAC layer using a body key 214, and encrypt the header 234 of the frame at the MAC layer using a header key 216. The encryption of the body 232 of the frame 230 at the MAC layer using the body key 214 may be performed simultaneously with the encryption of the header 234 of the frame at the MAC layer using the header key 216.

[0082] The encryption engine 222 may include functionality to identify at the MAC layer one or more frames 230 to be encrypted for wireless communication and to encrypt at the MAC layer a second frame 230 (e.g., a retransmitted frame) of a second network packet using the body key 214 of the second body 232 and the header key 216 of the second header 234 (e.g., the second frame). For example, the retransmitted frame 230 may have its header key 216 and its header MIC 244 recalculated to account for any changes in the header parameters 236, such as the packet number parameter or any other parameters that may have changed in the header 234.

[0083] The message integrity code (MIC) engine 240 may include any combination of hardware and software for calculating or generating a message integrity code (MIC) for any portion of the frame 230. The MIC engine 240 may include functionality for generating any cryptographic code for verifying the integrity of the transmitted frame. The MIC engine 240 may calculate a MIC for any frame 230 or header 234 (e.g., a frame MIC 242, a header MIC 244, an expected frame MIC 272, or an expected header MIC 274). The MIC engine 240 may generate a frame MIC 242 and a header MIC 244, which may be appended to the transmitted data to detect unauthorized changes or tampering during transmission between the sender device 202 and the recipient device 204. The MIC engine 240 may calculate a MIC for an encrypted frame (e.g., 242, 244, 252, or 272, 274, 276) using a hash-based algorithm. For example, the MIC engine 240 may calculate a frame MIC 242 for the encrypted frame 230 using the body key 214 and a header MIC 244 for the frame at the MAC layer using the header key 216. The MIC engine 240 may generate any MIC (e.g., 242, 244, 252, 272, 274, or 276), which may include a cryptographic checksum generated for a portion of a frame (e.g., a portion of the body 232 or header 234) or for a portion or the entirety of the frame 230.

[0084] The frame MIC 242 may include any cryptographic code calculated by the MIC engine 240 for verifying the integrity of the frame 230 transmitted from the sender 202 to the receiver 204. The frame MIC 242 may be sent with the frame 230 or appended to the encrypted frame data. The frame MIC 242 may be used by the receiver to compare with the expected frame MIC 272, which the receiver device 204 may independently calculate to compare and detect whether the received frame contains any unauthorized modifications or tampering. For example, in a wireless communication system, the frame MIC 242 may be calculated using a hash-based algorithm applied to the encrypted frame, thereby providing the receiver with a method for checking the integrity of the received data.

[0085] The header MIC 244 may include any cryptographic code calculated by the MIC engine 240 for verifying the integrity of the header 234 of the frame 230 transmitted from the sender 202 to the receiver 204. The header MIC 244 may include a cryptographic code calculated by the MIC engine 240 to verify the integrity of the header information within the frame 230 during transmission. The header MIC 244 may be appended to the encrypted header data and may be used by the receiver device 204 to detect any unauthorized modification or tampering of the header. This may be achieved by comparing the expected header MIC 274, which the MIC engine 240 of the receiver device 204 may generate to compare with the header MIC 244 received with the incoming frame 230. For example, in a wireless network, the header MIC 244 may be calculated using a hash-based algorithm applied to the encrypted header, thereby enabling the receiver to verify the integrity of the header data.

[0086] The expected frame MIC 272 may include any cryptographic code calculated by the MIC engine 240 of the recipient device 240 to be used as a reference value for comparison with the received frame 230 and verification of its integrity. The expected frame MIC 272 may be generated or calculated based on the content of the received frame, including, for example, both the body 232 and the header 234 of the frame 230. The expected frame MIC 272 may be calculated using a predetermined algorithm and the TK 212 that may have been previously shared with the recipient device 204. The expected frame MIC 272 may be calculated using the TK 212 generated from the master key 218, which may be exchanged between the devices 202 and 204 during a handshake or negotiation sequence between the two devices. For example, upon receiving the frame 230, the recipient device 204 may recalculate the frame MIC 242 using the same algorithm and compare it to the expected frame MIC 272. If the calculated frame MIC matches the expected frame MIC, the ICF 270 may determine and indicate that the frame content has not been tampered with during transmission. This comparison mechanism can be used to check the integrity of the entire frame, providing assurance against unauthorized modification.

[0087] The expected header MIC 274, also generated by the MIC engine 240 of the recipient device 204, may include any cryptographic code to be used as a reference value for comparison with the received header 234 and verification of its integrity. The expected header MIC 274 may be generated by the MIC engine 240 as an independent derivation of the header 234 by the recipient device 204 to compare with the header MIC 244 of the received frame 230. As with the expected frame MIC 272, the expected header MIC 274 may be calculated using a predetermined algorithm based on the header 234 content. Upon receiving the frame 230, the recipient device 204 may extract the header MIC 244 transmitted with the frame 230 and compare the header MIC 244 with the expected header MIC 274 that may be generated from the received header 234 data. If the received header MIC 244 matches the expected header MIC 274, then the ICF 270 may determine and indicate that the header 234 contents have not been tampered with during transmission, and the frame 230 may be verified or validated as safe for processing.

[0088] The MIC combiner 250 may include any combination of hardware and software for integrating the individual frame MIC 242 and header MIC 244 of the frame 230 to form a combined MIC 252 that encompasses the header 234 and the body 232. The combined MIC 252 may include any cryptographic code formed by integrating the individual frame and header MICs using the MIC combiner 250. The MIC combiner 250 may combine hardware and software elements to perform an operation that combines two or more MICs (e.g., 242 and 244). The operation that the MIC combiner 250 may use to generate the combined MIC 252 may include any reversible operation, such as an XOR operation, in which the frame MIC 242 and the header MIC 244 are combined in a bitwise XOR operation, in which each bit of the output is the result of applying the XOR operation to the two operands of the two MICs. The operation may include any reversible operation in which each bit of the output is the result of applying the operation to the input operands of the two MICs. The operation may include the concatenation of the frame MIC 242 and the header MIC 244 into a single string. For example, in a wireless communication system, the MIC combiner 250 may apply an XOR operation to the frame MIC 242 and the header MIC 244 to form a combined MIC 252, which may be transmitted to a receiving party for integrity verification. For example, the combined MIC may be generated using one or more or any combination of the following: a concatenation of the first MIC and the second MIC, a bitwise exclusive OR (XOR) calculation applied to the first MIC and the second MIC, or a bitwise AND calculation applied to the first MIC and the second MIC.

[0089] The expected combined MIC 276, also generated by the MIC engine 240 of the recipient device 204, may include any cryptographic code to be used as a reference value for comparing with and verifying the integrity of the received combined MIC 252. The expected combined MIC 276 may be generated by the MIC engine 240 as a derivative of the expected frame MIC 272 and the expected header MIC 274. The expected combined MIC 276 may be combined from the expected frame MIC 272 and the expected header MIC 274 using a MIC combiner 250 (e.g., deployed on the recipient device 204) using the same or similar operations as those used to create the combined MIC 252 (e.g., XOR or AND bitwise operations or concatenation of two MICs). For example, upon receiving the frame 230, the recipient device 204 may extract the combined MIC 252 and compare it to the expected combined MIC 276 derived independently on the recipient device 204 (e.g., using MICs 272 and 274). If the received combined MIC 252 matches the expected combined MIC 276, then the ICF 270 may determine and indicate that the frame 230 is authenticated or validated as safe for use and processing.

[0090] The coordinator 260 may include any combination of hardware and software for establishing, configuring, and managing communications between devices in a network. The coordinator 260 may combine hardware and software elements to coordinate data exchanges and ensure that the network operates properly. For example, in a wireless communication system, the coordinator 260 may facilitate the establishment of secure connections between devices, manage network resources, and resolve communication conflicts to maintain smooth operation.

[0091] Integrity check function (ICF) 270 may include any hardware and software for checking and verifying the integrity of an incoming frame using the MIC of sender device 202 and the expected MIC of recipient device 204. For example, ICF 270 may include functionality to extract any of the MICs (e.g., 242, 244, or 252) of an incoming frame from frame 230 and compare such MICs to an expected frame MIC 272 or expected header MIC 274 of recipient device 204. In response to determining that the MIC of sender device 202 (e.g., 242, 244, or 252) matches the MIC of recipient device 204 (e.g., 272, 274, or 276), ICF 270 may determine that the incoming frame 230 is verified. For example, in a wireless network, the ICF compares the received combined MIC to the calculated MIC of the frame or header to verify the integrity of the transmitted data before further processing. For example, the recipient device 204 may be configured to determine the integrity of the header 234 based on the verification of the integrity of the header 234 using the header MIC 244 before decrypting the frame. The recipient device 204 may be configured to verify the integrity of the header 234 of the frame using the header MIC 244 before processing the body of the frame.

[0092] Figure 3 An example flow chart illustrating a method 300 for providing encryption for MAC header protection according to a technical solution. The method 300 may use, for example, at least in conjunction with Figures 1A to 2 The functional implementation discussed may include actions or operations 302 through 320, which are indicative of actions taken or performed by the example system (eg, 200) during the course of an encryption process.

[0093] In one example, the method 300 may begin by initializing with specific values ​​and defining a block based on the length of an initialization vector (IV). This may be followed by data encryption using AES-ECB with a given key and processing the output through a hash function. The resulting hash value may be utilized in a GHASH operation along with additional header data and ciphertext to provide an output. Additionally, block J may be constructed based on the IV and other parameters, and the ciphertext may be encrypted using AES-CTR. A frame MIC may be generated, and a combining operation may be performed to obtain a final combined MIC, which may include components of the frame for integrity verification. Finally, an additional MIC may be generated, denoted as MHP MIC (T2).

[0094] At 302, the method may include input processing according to 0^128 (standard) UHR||0^125 (MHP). For example, the method may include processing input data, such as generating an initialization vector (IV), which may include one or more unique values ​​to initialize an encryption mechanism, such as AES in counter mode. The IV may then be combined with other data to produce an output.

[0095] At 304, the method may include AES electronic codebook (ECB) mode encryption. This block performs AES encryption in electronic codebook (ECB) mode using a key (K). ECB mode encrypts each block of data independently, making it suitable for parallel processing.

[0096] At 304, the method may include an AES-ECB encryption algorithm with a key (K). AES-ECB may include a block cipher mode of operation that encrypts individual blocks of plaintext individually to provide security by introducing a degree of randomness in the encryption. Input data may be encrypted using the AES algorithm to produce ciphertext.

[0097] At 306, the method may apply a hash function to the data output at operation 302. The hash function may be a hash-subkey function that processes the data provided at action 304 to generate a hash value. This hash function may generate a unique fixed-size hash value for input data of any size. The output may be provided to operation 310.

[0098] At 308, the method may utilize header data processing, which involves the manipulation or analysis of header information within a communication frame. The header data may include parameters and metadata, including any control information for routing and processing the data payload. An output may be provided to operation 310.

[0099] At 310, the method may utilize an encryption function such as a GHASH function. The GHASH function may be based on a Galois / Counter Mode (GCM) encryption algorithm and may be used for encryption authentication and integrity verification of data. This encryption function may calculate a message authentication code (MAC) using Galois field multiplication and provide its output to operation 314.

[0100] At 312, the method may generate a counter (CTR) value that may be used for AES encryption in a counter mode of operation. The CTR value may be derived from an initialization vector (IV) and a packet number (PN), which may be used to generate a key used in encryption. The output may be provided to operation 314.

[0101] At 314, the method may implement AES-CTR encryption using a counter (CTR) mode of operation with the AES algorithm. AES-CTR may encrypt plaintext by XORing the plaintext with a key (e.g., a keystream) generated from a CTR value. This resulting output of the combined or XORed data provides an additional level of integrity because it produces ciphertext with an encoded counter value. For example, if a packet number (PN) parameter from a header of a frame in a series of frames is utilized, the output will be unique to the transmission instance, such that if retransmitted frames are tampered with by an attacker, the frames will be detected at the receiving device.

[0102] At 316, the method may calculate a frame MIC (Message Integrity Code), which may include a cryptographic checksum generated for the entire frame to verify its integrity during transmission. The frame MIC may facilitate verification that the transmitted frame has not been maliciously altered or corrupted during transmission.

[0103] At 318, the method may combine the frame MIC from operation 316 with the data output from operation 314 (e.g., AES-CTR encryption) using a specified combining function. The combining function may include an operation such as an XOR (exclusive OR) or concatenation to merge the frame MIC with the data output from operation 314. The resulting output may be or include a combined MIC for the frame, which may be used as a comprehensive integrity verification measure for verifying the frame integrity of the transmitted frame at a recipient device.

[0104] At 320, the method may include the generation of another MHP MIC (Message Integrity Code) that acts as a cryptographic checksum for the MHP protocol. This MIC may be used to verify the integrity and authenticity of data transmitted using the MHP protocol.

[0105] Reference now Figure 4 , illustrates an example block diagram of a method 400 for implementing Galois Counter Mode (GCM) encryption to generate MIC according to a technical solution. The method 400 may use, for example, at least in combination with Figures 1A to 2 The functional implementation discussed may include actions or operations 402 through 426, which indicate actions taken or performed by the example system (eg, 200) during encryption.

[0106] For example, in method 400, a system or configuration for GCMP MIP determination in the Wi-Fi standard may involve a pairwise transient key (PTK) or a group transient key (GTK) for the UHR MAC header MIC. Since the GHASH subkey in GCM may contain the AES encrypted text of plaintext 0, it is difficult to obtain the key (K) and damage the data even if the text is known and even if the attacker knows the subkey. Similarly, a pattern (e.g., "5555" or "ffff") may be used as an AES input, and its ciphertext may be used as a key for header MIC calculation. In the case of 256-bit GCMP, the solution may include two patterns.

[0107] At 402, the method identifies a key as input. The key (e.g., TK) can be used as an encryption key for the method. The key can be input into and used by multiple blocks or functionalities "AES(K)" of block 404, which perform AES encryption using the provided key. At 408, "AES(K)" processes the output of operation 406, which can use the AES encryption function to provide an output of a "0" bit. The output of operation 408 can be input into the identified operation 410, which can generate a subkey. The subkey can be utilized by operation 412, which can perform a GHASH operation, receive additional input (e.g., AAD+ciphertext) from operation 420, which can combine additional authenticated data with the ciphertext. At 414, the AES(K) operation can receive input (e.g., key) from operation 402 and receive input from operation 422. An initialization vector (IV) may be provided by operation 422, which may include blocks 424 (e.g., A2(6)) and 426 (e.g., a packet number parameter of the header) for generating the IV. The output of operation 414 may be fed into operation 416, which combines the signals from operations 412 and 414. At 418, the combined output from operation 416 is provided, which represents the generation of the MIC.

[0108] Reference now Figure 5 , illustrates another example block diagram of a method 500 for implementing Galois Counter Mode (GCM) encryption to generate MIC according to a technical solution. The method 500 may use, for example, at least in combination with Figures 1A to 2 The functional implementation discussed may include actions or operations 502 through 528, which indicate actions taken or performed by the example system (eg, 200) during encryption.

[0109] Method 500 may correspond to a diagram of the operation of system 200 using a configuration for key generation and GCMP for header MIC. In one aspect, the illustrated example may provide key generation and GCMP for header MIC, where the same GCMP is still used and key generation may be employed. In the 256-bit case, two modes may be defined for the upper and lower 128 bits of the key K'. For example, if a frame does not contain a payload, it may have a MIC outside of the MAC header (existing PTK / GTK may be used), and the frame with the payload may be protected using existing mechanisms. In such an example, there may not be two levels of credential verification for a single frame (e.g., one MIC verification for the header and another for decrypting the payload).

[0110] At 502, an input stream for an AES function may be identified. The input stream may include a predetermined fixed pattern. The output from 502 may be used as an input to 504, which may include an AES(K) function. The output from 504 may be an input to 506, which may correspond to the K' output of the AES encryption algorithm. The output from 506 (e.g., K') may be used as an input to 510 and 524. Function 510 may include an AES encryption of K' with another input from 508, which may include a value of "0" (e.g., padding).

[0111] The output from 510 may be provided as an input to 512, which may correspond to a subkey. The output from the subkey may be provided as a first input to a GHASH function at 516. A second input to 516 may be provided from 514, in which additional authentication data (AAD) is identified. The output from GHASH may be provided as a first of two inputs to 526, which may include a signal combiner for combining two signals. The second input to the 526 combiner function may come from an AES(K') operation at 525. 525 may receive an IV as its input from 522. At 522, two blocks may be included to provide an IV, the first block being an operation 518 with A2(6), and the second block being an operation 520 with a packet number (PN(6)), which may be used to generate an IV. The second input to 524 for generating an AES(K') function may be an input from 506 (e.g., K'). The output from 526 is a MIC, which may be provided at operation 528 using the output from 526 .

[0112] Reference now Figure 6 , illustrating an example 600 of the arrangement of the header 234 of the frame 230. In the example 600, the IV-body may indicate whether MAC Header Protection (MHP) is applicable. In the instance where MHP is applicable, the IV-body may indicate whether it requires an integrated IV and ICV or a separate Header IV and Header ICV configuration.

[0113] The header 234 may be represented as a table of bytes, where each field or slot in the table corresponds to a particular byte or bit set within the header 234. The header 234 may include a plurality of parameters 236 arranged in respective slots of the header 234. The parameters 236 may include a packet number (PN), such as PN0, PN1, a shorter version of the PN (e.g., a short PN header), and IV data, such as extended initialization vector plus (EXT IV+) data. The parameters 236 of the header 234 may include slots arranged in a sequence of packet numbers for tracking packet numbers within a communication flow.

[0114] Zooming in on the "EXT IV+" slot, showing bit-level information for EXT IV+. The bits for EXT IV+ may correspond to bits that may be reserved for various functionalities, such as RSVD[B0], MHP, RSVD[B2], Integrated ICV, FTM, EXT IV, and Key ID. In some instances, these bits may represent different attributes or flags associated with an extended initialization vector (IV). For example, the "MHP" bit may indicate whether the header 234 has MHP functionality. In such a configuration, an MHP of 0 may indicate that MHP is not applicable to this frame 230, while an MHP of 1 may indicate that MHP may be utilized. For example, the Integrated ICV bit may specify whether the header 234 includes an Integrated Integrity Check Value (ICV), which may be used to verify the integrity of the header data. For example, the Key ID bit may be implemented to indicate a specific encryption key 210 that may be used for a frame or the body of a frame.

[0115] Reference now Figure 7 , illustrating an example method 700 for providing MAC address protection. The method 700 may be a method for providing protection of a machine access control (MAC) header of a frame. The method 700 may be implemented using, for example, the systems 100 and 200 and in combination with Figures 1A to 6 The method 700 may include actions 705 to 720. At 705, the method may include identifying a temporary key. At 710, the method may include calculating a first key for a frame body and a second key for a frame header. At 715, the method may include encrypting the body using the first key and encrypting the header using the second key. At 720, the method may include calculating a first MIC for the frame and a second MIC for the header using the first and second keys.

[0116] At 705, the method may include identifying a temporary key. The method may include one or more processors of a sender device identifying a temporary key (TK) programmed in hardware. The TK may be stored, for example, in a storage device (e.g., non-volatile memory) or programmed in a dedicated hardware module. The TK may be generated during initialization of the sender device or during a negotiation or handshake between the sender device and the recipient device. The TK may be generated based on a master key negotiated between the sender and recipient devices during initiation or establishment of a connection or session between the devices.

[0117] The sender device may identify or use the TK to encrypt frames at the machine access control (MAC) layer for wireless communication. For example, one or more processors of the sender device may use the TK as an input to one or more encryption functions or algorithms (e.g., AES) to generate one or more keys for encrypting one or more parts of a frame (e.g., a network packet). For example, the TK may be used to generate a body key for encrypting the body of the frame and a header key for encrypting the header of the frame. The header and body keys may be customized or configured to cover the body and header at any layer, including the data link or MAC layer of a frame, such as a frame for a WLAN or Wi-Fi network.

[0118] At 710, the method may include calculating a first key for the body of the frame and a second key for the header of the frame. The method may include one or more processors of the sender device using TK to calculate a first key (e.g., a body key) for encrypting the body of the frame and a second key (e.g., a header key) for encrypting the header of the frame. In some implementations, the first key and the second key may be the same. In some implementations, the second key may be different from the first key.

[0119] The method may include one or more processors calculating a first key using a hash-based message authentication code (HMAC) operation. The HMAC operation may include a first input of TK and a first fixed pattern. The method may include using a hash-based message authentication code (HMAC) operation or an AES encryption operation to calculate the first key using either a first input of TK and a first fixed pattern. The first pattern may include a string. The string may be a predetermined string shared between a sender and a receiver device. The method may include one or more processors calculating a second key using an HMAC operation with a second input of TK and a second fixed pattern. The second fixed pattern may include a string that can be shared between a sender and a receiver device. The first fixed pattern may include a packet number (PN) of a network packet of a frame, and the second fixed pattern may include one or more characters of a body.

[0120] The one or more processors may include using an Advanced Encryption Standard (AES) operation to calculate a first key for the body. The AES operation may include a first input of a TK and a first fixed pattern. The method may include the one or more processors calculating a second key for a header of a frame. The same AES operation with a second input of the TK and a second fixed pattern may be used to calculate the second key for the header of the frame. The one or more processors may use an AES operation with a first input of the TK and a first fixed pattern to calculate the second key for the header, and use the TK as the first key for the body of the frame.

[0121] At 715, the method may include encrypting the body using the first key and encrypting the header using the second key. The method may include one or more processors identifying, at the MAC layer, one or more frames to be encrypted for wireless communication. For example, a sender device may identify frames that were not successfully received by a recipient device. In response to determining that a frame was not received at the recipient, the sender device may identify a frame to be resent to the recipient.

[0122] The method may include one or more processors of a sender device encrypting a body of one or more frames at a MAC layer using a first key (e.g., a body key). The method may include one or more processors of a sender device encrypting a header of one or more frames at a MAC layer using a second key (e.g., a header key). The method may include encrypting one or more values ​​in one or more fields of a header, the fields including a packet number of a frame that identifies a header within a sequence of frames sent from a sender to a receiver.

[0123] The method may include generating an initialization vector (IV) for encryption. The IV may be generated using one or more parameters of a frame. The one or more parameters may include a packet number of the frame. The IV may be generated using a concatenation of a packet number (PN) with additional parameters (e.g., a fixed pattern). This may produce a unique initialization vector for each frame, allowing detection of frames whose headers have been intercepted and tampered with by a third party (e.g., an attacker or hacker). The IV may be derived from the header data itself. The IV may incorporate specific fields, such as the packet number and other header parameters to facilitate uniqueness and encryption strength during the initialization process. The method may use the IV to encrypt the body of the frame. The method may use the IV to encrypt the header of the frame.

[0124] At 720, the method may include calculating a first MIC for the frame and a second MIC for the header using the first and second keys. The method may include one or more processors of the sender device calculating, determining, or generating a first message integrity code (MIC) for the encrypted frame. The first MIC for the frame may be calculated, determined, or generated using the first key (e.g., the subject key). The method may include one or more processors calculating, determining, or generating, at the MAC layer, a second MIC for contents of the header of the frame using the second key.

[0125] The method may include one or more processors transmitting a frame having a first MIC (e.g., a MIC of a frame) and a second MIC (e.g., a MIC of a header) to a receiver. The method may include one or more processors causing the frame to be transmitted with the first MIC (e.g., a MIC of a frame) and the second MIC (e.g., a MIC of a header) via a transceiver of a sender device (e.g., a communication link circuit system having an antenna configured for wireless transmission). The receiver device is configured to determine the integrity of a header of the frame based on at least the second MIC (e.g., a MIC of the header). For example, the receiver device may include an integrity check function and a MIC engine that may generate an expected header MIC. The integrity check function of the receiver device may compare the expected header MIC with the MIC of the header received with the frame. If the MIC of the header matches the expected header MIC, the integrity check function may determine that the incoming frame has not been tampered with and may decrypt and process the frame and its payload (e.g., body).

[0126] The method may include one or more processors generating a combined MIC from a first MIC (e.g., a MIC of a frame) and a second MIC (e.g., a MIC of a header). The frame may correspond to a beacon transmission. The combined MIC may include the first MIC, and the second MIC may include a timestamp. For example, the second MIC may be a timestamp. The combined MIC may be based on or include at least a portion of the first MIC and at least a portion of the second MIC. The method may include one or more processors transmitting the combined MIC to a recipient to determine the integrity of the frame. The combined MIC may be generated using any reversible operation. For example, the combined MIC may be generated using any one or more of the following: a concatenation of the first MIC and the second MIC, a bitwise exclusive OR (XOR) calculation applied to the first MIC and the second MIC, or any bitwise reversible calculation applied to the first MIC and the second MIC.

[0127] For example, the method may include the sender device calculating the first MIC once, such as once for a given body of data or beacon. The method may include the sender calculating the second MIC for each retransmission or beacon transmission. The second MIC may be combined with the first MIC at each transmission or retransmission or beacon transmission, such that the first MIC is not updated for a transmission or beacon transmission, but the second MIC and / or the combined MIC is updated for each retransmission.

[0128] The method may include a receiver determining the integrity of the header and body by calculating an expected first MIC using an expected second MIC and then verifying whether the expected first MIC (of the body) is correct. For example, the expected second MIC may be independently calculated at the receiver using the same or similar process as generating the second MIC at the sender. The receiver may compare the expected second MIC with the second MIC received with the frame. For example, the sender may include a combined MIC with the frame transmission, wherein the combined MIC includes a combination of the first MIC and the second MIC in the same space or portion of the frame. The receiver may be configured to verify the integrity of the incoming frame by calculating the expected first MIC using the expected second MIC and then verifying whether the expected first MIC (of the body) is correct. It may be assumed that the header MIC is correct, and the body MIC may be used to verify the header MIC and determine that the header MIC is correct in response to determining that the body MIC is correct.

[0129] The method may include using a first fixed pattern that includes at least a portion of the content of the body. The second fixed pattern may include one or more of the packet numbers (PNs) of the body of the network packet for the frame. The PN of the body used in the fixed pattern can be used for all retransmissions of the frame. For example, the first fixed pattern or the second fixed pattern may include a frame type, such as information indicating a control frame that may have a key different from a management frame and a data frame. The second fixed pattern may include one or more link addresses, such as a link address for multi-link operations, where the link can be used to transmit the frame. The PN may include one or more bytes. For example, a single byte PN may be used with a first key or a second key. For example, the second key may be derived based on the PN of the body, which is longer than one byte and may remain unchanged (e.g., pre-existing) in multiple retransmissions. The frame may correspond to a first network packet in a plurality of network packets. The first network packet may include a first packet number in a header of the frame. The method may include one or more processors determining to resend the first network packet as a second network packet, the second network packet having a second packet number in a second header of a second frame of the second network packet. The second packet number may be different from the first packet number. The second network packet may uniquely identify a network packet to be sent from the sending device from any other network packets in a series of network packets transmitted over a period of time.

[0130] The one or more processors may include calculating a first key for a second body of a second frame of a second network packet and a second key for a second header of the second frame using TK. The first key of the first network packet may be different from the first key of the second network packet. The first key for the second body of the second frame of the second network packet may be the same as the first key for the body of the frame of the first network packet. The method may include the one or more processors identifying one or more frames to be encrypted for wireless communication at the MAC layer. The method may include the one or more processors encrypting the frame of the second network packet at the MAC layer using the first key for the second body and the second key for the second header.

[0131] In an example, during a network communication exchange, when a retry of a transmission occurs (e.g., a second attempt to transmit data after an initial unsuccessful attempt), some MAC header fields may be altered by a malicious actor without system authentication. In some instances, the altered fields may be masked in the Additional Authentication Data (AAD). This vulnerability may facilitate malicious attacks by unauthorized actors, such as when hackers exploit fragmented frames. For example, some of the affected fields may include Potential Saving, More Bits, and SPP / Aggregation. Both CCMP and GCMP may calculate MICs based on chaining, such as by using a cipher block hash (CBC MIC in CCMP) or a GHASH for the last cipher block. It may be beneficial to calculate a MIC based on the originally calculated packet MIC, thereby providing authentication for the altered fields, because such solutions are easily computable within a short interframe space (SIFS) and may maintain a format that is consistent, the same, or similar to the previous format.

[0132] Aspects of the technical solution involve extending existing security mechanisms to reuse encryption keys for MAC header protection. The technical solution minimizes the creation of additional hardware and firmware for MAC header protection. Current CCMP and GCMP mechanisms can be used or extended to integrate MIC for MAC header protection without changing the frame format. This can reduce space or architecture. If encryption is desired, the same key can be used, where the frame carries additional encrypted data. The technical solution can allow different IVs to be generated using PN. This approach can facilitate solving challenges in WLAN standards (such as 11bn deployments). A set of different keys can be used, thereby utilizing space / fields for encrypted header field information, which can be utilized in Wi-Fi communications to provide a balance between higher security and lower cost.

[0133] The technical solution may utilize CCMP and GCMP functionality, which may be used as in its previous configuration or infrastructure. For example, the system may be configured to not include encryption of the frame body 232 when retransmitting a network packet (e.g., frame 230). The technical solution may include a key K 214 for MHP (MAC header protection). The key K 210 may be derived from the original key K used for transmission (e.g., TK 212). For example, the key K may be defined as K=E(K orig ,P1) or E(K orig ,P1)||E(K orig ,P2), where P1 and P2 are fixed patterns, such as 12345||0^123,UHR||0^125.

[0134] For example, in the GCMP configuration of the solution, if encryption is not used, then K can be equal to K orig The same. H may be the seed hash for GHASH H=E(K,P1), where P1 is a fixed pattern. The technical solution may transmit the MIC original CCMP / GCMP T, which may be XORed (e.g., processed using an exclusive OR) with the MHP T (e.g., header MIC 244), which may be calculated on header 234 as the MIC for transmission. The technical solution may use the same PN and perform the same replay check as in the previous system implementation.

[0135] In some examples, if a retry of a transmission (e.g., a retransmission) is to be encrypted or the MIC tested before the entire frame 230, the solution may transmit the MHP IV with the retry number—a small PN, also send the encrypted block with the small PN, or when decrypting—use the small PN to determine that the retry is unique. In some examples, the technical solution may calculate the MHP T (e.g., the header MIC 244) and XOR the MHP T with the received information (e.g., the previously transmitted public key 210). The result may be the original T, which may allow for comparison and determination of the integrity of the transmission. The technical solution may decrypt using the original CCMP / GCMP, and the replay check may verify whether the MHP was replayed.

[0136] At a high level, the key derivation process may be extended to derive K-MHP (K MAC Header Protection), while in some implementations, only K-Body may be used. Encryption and integrity protection may be achieved through Authenticated Encryption with Associated Data (AEAD) and may be consistent for the body with IV-Body, C-Body, and T-Orig components. In some instances, header encryption may be performed and header integrity may be protected. This may involve, for example, IV-Header, C-Header, and T-Header elements. A transmitted or received frame after protection of the Frame Check Sequence (FCS) is not shown may include the following structure:

[0137] · <header> [ <iv-header> [ <c-header> ]] <t-header> <iv-body> <c-body> <t-orig>

[0138] · <header> [ <iv-header> [ <c-header> ]] <iv-body> <c-body> ( <t-orig>⊕<T-Head er>)

[0139] · <header> <iv-body> <c-body> ( <t-orig> ⊕ <t-header>)

[0140] In the process of key derivation, the process of key derivation may include the cascade of several components, including a key confirmation key (KCK), a key encryption key (KEK), a temporary key (TK), and a key derivation key (KDK). Such a cascade may be performed using a hash-based message authentication code using a key derivation function (HMAC-KDF-NNN) function with a pairwise master key (PMK) as input key material. The function parameters may include a "pairwise key extension" as an information parameter, as well as various combinations of values ​​derived from AA (authentication algorithm), SPA (selected pairwise algorithm), ANONCE (authentication random number), and SNONCE (requesting party random number). These values ​​may be manipulated and passed into the HMAC-KDF-NNN function to generate a derived key. The process may be expressed as:

[0141] KCK||KEK||TK||KDK=HMAC-KDF-NNN(PMK, "Pairwise Key Extension", MIN(AA,SPA)||MAX(AA,SPA)||MIN(ANONCE,SNONCE)||MAX(ANONCE,SNONCE))

[0142] In one example, a technical solution may include TK 212 that may be used as K-Body (e.g., body key 214), where K-Header is not present. In one aspect, a technical solution may include TK 212 as a combination of K-Header (e.g., header key 216) and K-Body (e.g., body key 214). In one aspect, a technical solution may include deriving K-Header and K-Body via HMAC-KDF-NNN that may utilize one or more different fixed patterns. For example, K-Header may be determined using HMAC-KDF-NNN(TK, FixedPattern1), and K-Body may be determined as HMAC-KDF-NNN(TK, FixedPattern2). In one aspect, the technical solution may include: K-Header=AES(TK,FixedPattern3), K-Body=AES(TK,FixedPattern4); FixedPattern3 is 0123^0128, and FixedPattern4 is 0128; FixedPattern1 is "Header", and FixedPattern2 is "Body".

[0143] In one aspect, a technical solution may include not exposing the PMK to hardware, leveraging an existing AES engine in hardware, using different keys to improve security, and using temporary key programming in hardware. In one aspect, a technical solution may use an AES-based derivation for the K-Header and TK for the K-Body, leveraging a pattern. For example, a solution may utilize a feature that can be expressed as follows: K-Header = AES(TK, FixedPattern5), K-Body = TK; FixedPattern5 is 0123^0128.

[0144] With respect to transmission and reception, in some aspects, an IV-Header and a C-Header may be used. The IV Header may allow for MIC checks and replay checks before the body is processed. For example, the C-Header may provide header encryption fields and / or obfuscation. In some instances, a separate T-Header may be included. The technical solution may allow for MIC checks and replay checks before the body is processed. In some aspects, a combined header may be used with no or minimal changes to the frame format. For example, the T-header may be used to calculate the T-Orig, and existing processes may be used to verify the T-Orig. Current replay checks may be used to trust the header, and the results may be in <header>as output.

[0145] General security considerations may provide a preference to prevent security attacks and minimize the number of keys involved. For example, the counter / IV may not be the same, but the key may be the same. Masked fields may be authenticated. In some instances, fields may not be encrypted. Replay checks may or may not occur. Encrypted payloads may not be re-encrypted. MAC header protection may be combined with MPDU encryption to reduce additional key material. The technical solution may not include changes to CCMP / GCMP.

[0146] The CCMP may include M, which indicates the length of the MAC, which may be 8 or 16 octets. Ke may be a key of 16, 24, or 32 octets. The MIC key may be an encryption key. For example, the technical solution may use E(K,P1), E(K,P1)||E(K,P2) as 128-bit and 256-bit K for the MHP CCMP. P1 and P2 are fixed patterns, such as: 54321||0123, 12345||0123. For example, the technical solution may include the following configurations, such as:

[0147] ·Si:=E(K,Ai), for i=0,1,2,…;Ai= <flags:1> <nonce:13> <blockcounteri:2>, which may represent the encryption of data blocks (Ai) in sequence using a key (K), where each block Ai may include parameters, such as a flag, a random number, and a block counter, which may be combined to form an input for encryption.

[0148] X1: = E (K, B0); B0 is the CCM flag, length (AAD), AAD (the last block 0 is padded), P; For i=1,…,n, it may represent an encryption process for CCM (Counter with CBC-MAC) mode, involving encrypting an initial block (B0) using a key (K), and then iteratively encrypting subsequent blocks (Xi) by XORing them with the previous block (Bi) before encryption.

[0149] AuthCode:=L(Xn+1,M); It may represent an authentication code (Auth Code) calculated based on the length of the last encrypted block (Xn+1) and the message (M). This code may be combined with the derived value (S0) to generate an ICV or Auth Tag.

[0150] Plain text: P; Cipher text: It may indicate that plaintext (P) is transformed into ciphertext (Ci) using the encryption process described above, where each block of ciphertext is derived by XORing the corresponding block of plaintext with the output of the encryption function.

[0151] The technical solution may include a transmission from the sender device 202 to the receiver device 204, which may be represented as: A(IV), C(ciphertext), T1(ICV). For example, A(IV) may refer to the IV used for encryption, C(ciphertext) may represent the encrypted message or data, and T1(ICV) may indicate an integrity check value (ICV) or authentication tag associated with the encrypted frame.

[0152] The Galois / Counter Mode Protocol (GCMP) may include a cryptographic protocol for secure communications in, for example, wireless networks, and provide encryption and integrity protection for data frames. GCMP may include configurations such as:

[0153] H=E(K,0 128 ); the hash key is the 0 block encrypted with the key; the 0 block may contain another selected one of H, such as 54321||0 123 For example, the technical solution may use E(K,P1), E(K,P1)||E(K,P2) as the 128-bit and 256-bit K of the MHP GCMP. P1 and P2 may be fixed patterns, such as 54321||0123, 12345||0123.

[0154] If len(IV) = 96, then Y0 = IV||0 31 , otherwise GHASH(H,{},IV); Yi=incr(Yi-1) This may indicate the initialization of the counter value (Yi) used in the encryption process. If the length of the initialization vector (IV) is 96 bits, then Y0 may be formed by concatenating the IV with a 32-bit value of 0. Otherwise, it may be calculated using a GHASH function with a hash key (H) and IV, where subsequent counter values ​​(Yi) are derived by increasing the previous counter.

[0155] · For i=1,…,n-; - A final block, which may represent the encryption process in GCMP, where each block of ciphertext (Ci) is obtained by XORing the corresponding plaintext block (Pi) with the output of encrypting the counter value (Yi) using the encryption key (K). The final block of ciphertext (C*) may be derived similarly, with an additional XOR operation involving the most significant bits of the encrypted output.

[0156] · This may correspond to the determination of an integrity check value (T1) or an authentication tag for the transmitted data. It may include a GHASH function that calculates a hash value based on a hash key (H), the associated data (A), and the ciphertext (C). The bits of this hash value may then be combined with the output of encrypting the initial counter value (Y0) to generate the final authentication tag.

[0157] • The technical solution may then be transmitted from the sender device 202 to the receiver 204 as expressed by: A(IV), C(ciphertext), T1(ICV).

[0158] Technical solutions may include separate MHP keys. For example, a technical solution may insert an MHP header protected by an MHP key. For example, packet X may include MHP||MHPX||BX||TX. For example, packet Y may include MHY(changed MHX)||MHPY||B2|T2. For example, packet*=MHY||MHPY|BX||TX. Header protection may be changed and coupling between MHPHX and TX may be used. Technical solutions may include parallel mechanisms for HW key state, replay check state, algorithm negotiation, and key rotation.

[0159] Technical solution An octet counter D0...Dk-1 may be constructed. For example, the AES block size is 16 octets and the key is 16, 24 or 32 octets. For example, 4 octets / MHP prefix or zeros in D0- may be used to verify that T2 precedes T1. For example, A2||PN(original)||<changed field>—the last one provides counter uniqueness. For example, A2, PN, changeable fields may already be in the frame. PN may be reused, but the counter value may not be used for security.

[0160] For example, a technical solution may include configurations such as: (D is a block) CCMP, or for a longer D CCMP, Or for GCMP, When receiving, for example, (One block D) CCMP and decrypt ~IV||C||T1 as before. Technical Solution Can transmit: ~A(IV), C(ciphertext), T2(ICV). Trust the changed fields only after decrypting C and verifying T1.

[0161] For example, a technical solution may include advertising MAC Header Protection (MHP) in RSNXE. For example, Beacon, Probe Response, Association, and 4-WAY M2 / M2 may be used. Bits may be allocated (e.g., 15 is the maximum). UHR may use MHP. Keys may be reused. The verification order may include verifying T1, and then only trusting header fields that may have changed and included in T2 calculations. For example, if MHP replay detection is to be done first, then the prefix and E(K,D) are transmitted first, and replay is checked before processing the full frame using the current protection (CCMP, GCMP). Replay checks may be combined.

[0162] For example, a technical solution may include verifying T2 and the changed field before verifying T1. For example, the solution may change the frame format by including another field (e.g., a MAC security header). Another set of keys may or may not be used, as may the original PN, which can be verified later. There may be more bits in the payload, and one bit may be used to set so that the counter is not reused (e.g., the multicast bit in A2).

[0163] The technical solution may include multiple advantages. For example, the technical solution may maintain a consistent frame format without merging a MAC Header Protection (MHP) header. The number of unicast keys may not change, and the coupling of the MHP header with the tag from the body encryption may be emphasized to achieve security. Without such coupling, there may be a vulnerability in which the MHP header of one frame may be mixed with the body of another frame, resulting in a loss of protection of the changed header field. The same key, metadata algorithm, and packet number (PN) may be designed to work with MHP without requiring protocol changes, such as 4-way handshakes. To enhance security, there are no additional replay checks and corresponding transmission and reception states for the MHP keys; the operational channel verification (OCV) feature may assist in eliminating multi-channel man-in-the-middle (MITM) attacks. The technical solution makes minimal changes to current protocols and supports both CCMP and GCMP. Security vulnerabilities may be minimized by using the same key chaining block, similar to the approach in CCMP and GCMP.

[0164] In some implementations, the technical solution may include enhancements to beacon frame protection mechanisms within wireless networks, including improvements involving key derivation, frame format, and message integrity. The technical solution may include the use of a cipher-based message authentication code (CMAC) or Galois / counter code (GMAC) technology and Advanced Encryption Standard (AES) encryption to provide integrity and authenticity of beacon frames. Key derivation may be used to provide shared beacon integrity protection (BIP) key distribution during the association or handshake process, and may be used for encryption and calculation of message authentication codes (MACs). Frame format adjustments may include a management MIC element (MME) that includes a CMAC or GMAC tag and a timestamp field (TSF) that may be carried within the beacon. The technical solution may involve an update to the MME, replacing the existing MIC element with an AES-encrypted block derived from the timestamp and key, improving tamper-proof security. A hash function or a keyed hash function may be used for verification of the timestamp within the beacon frame, thereby facilitating improved data integrity and authenticity during wireless communications.

[0165] TSF (e.g., timestamp element) may be included in the solution. CMAC or GMAC may be utilized within the Beacon Integrity Protection (BIP) framework. BIP may be used to calculate the MIC sent to the MME. CMAC and GMAC may each use AES encryption or Galois hashing (GHASH) to protect the beacon frame. The technical solution may involve replacing the existing BIP mechanism with an encrypted AES block.

[0166] Challenges may include negotiation of keys, including cases where the keys remain unchanged and backward compatibility where new elements carry MICs with TSF. Furthermore, calculation of each TTBT may be avoided, and T is calculated and the MIC is incrementally updated using T and TSF.

[0167] In some instances, the frame format may include an MME, which may include an 8 or 16 byte CMAC tag T or a 16 byte GMAC. The MME may be a management MIC element. The TSF may include an 8 byte timestamp field. The TSF may be carried in a beacon. An authentication tag for T / MIC may be included. For BIP-GMAC, the tag may be 128 bits or 16 bytes. For BIP-CMAC, it may be 8 bytes for BPI-CMAC-128 or 16 bytes for BIP-CMAC-256. T may be calculated once for a beacon. The TSF may change for each beacon and may not be included in T.

[0168] A technical solution may involve key derivation. The same BIP key K may be used for encryption. For example, the same BIP (Beacon Integrity Protection) key (denoted as K) may be used for both encryption and cryptographic operations, such as CMAC (Cipher-based Message Authentication Code) or GMAC (Galois / Counter Mode), to compute a Message Integrity Code (MIC). Such a key K may be distributed as part of an association or four-way handshake process. For example, the key K may play a dual role to facilitate secure encryption of data and computation of a MIC to verify the integrity and authenticity of a transmitted message.

[0169] In the frame format specification, the Management MIC Element (MME) may include an 8 or 16 byte CMAC tag or a 16 byte GMAC tag. The MME may serve as a management component responsible for integrity checks within the frame. The frame may include an 8 byte timestamp field (TSF) and may be carried within the beacon frame. Currently the authentication tag or message integrity code (MIC), in the context of BIP (Beacon Integrity Protection) with GMAC, the tag may be set to 128 bits or 16 bytes. In the case of BIP-CMAC, the tag length may vary, for example, with 8 bytes allocated for BIP-CMAC-128 and 16 bytes allocated for BIP-CMAC-256. The tag (T) may be calculated once for each beacon frame. The timestamp field (TSF) may change with each beacon and may or may not be included in the calculation of the tag.

[0170] The technical solution may include a modification or update to the Management MIC Element (MME) using an AES encrypted block. For example, the Timestamp Field (TSF) found within the beacon frame may be used as a timestamp, where the symbol Represents an XOR operation. For example, within the MIC field of the MME, the same timestamp element may be encapsulated. The encryption process may include applying AES encryption using a key K to an XOR operation between the tag and a padded version of the TSF with zeros appended, resulting in a fixed size AES block of 16 bytes. The TSF may be padded with zeros to a size of T. Then, an XOR function may be applied with T, and the result may be padded with zeros to an AES block. Then, it may be encrypted using K to generate an encrypted block.

[0171] Upon receipt, the encrypted block can be decrypted using the key K to retrieve The estimated tag (T) can be obtained using the TSF extracted from the beacon frame. The estimated T can then be cryptographically verified using conventional Beacon Integrity Protection (BIP) mechanisms. Verification may fail if the TSF / timestamp in the beacon frame has been tampered with or modified.

[0172] The technical solution may also update the management MIC element (MME) using an additional hash function (denoted as H) or a keyed hash function (denoted as KH (e.g., CMAC, GMAC, SHA*)). The timestamp field (TSF) may be used as a timestamp within the beacon frame, which has an XOR sign Within the MIC field of the MME, the same timestamp element may be included. The process may involve concatenating the timestamp (T) with the TSF. Such a process may include or be followed by the calculation of H(T||TSF) or KH(K,T||TSF). Such a calculation may generate a new value T2, which may then be transmitted in place of T within the MIC. Upon reception, the receiver may employ an existing BIP mechanism to retrieve T using the key K. T may then be concatenated with the TSF from the beacon frame, and the expected T2 may be calculated using H or KH. The received T2 from the MME may be compared to the expected T2, and if they match, acceptance may occur; otherwise, the frame may be rejected. Encryption may be implemented as 802.11 hardware may include AES compatibility.

[0173] In some implementations, an actor familiar with the BIP key may send a beacon or impersonate an AP with a MIC as defined. Some considerations may include signing with a public and private key pair, where the MIC (e.g., element) in the MME may be a signature. For example, a signature for EC NIST P256 may include 64 bytes. Considerations may include sending an additional element AIMIC to avoid impersonating the MIC with a public key signature so that impersonation can be avoided by anyone with the BIP key. Considerations may include replacing the MIC or having the new MIC signed with AES and / or The hash of AIMIC is overwritten to avoid updating the public key signature at every TBTT / beacon interval to check if the TSF / timestamp is also verified.

[0174] Technical solutions may include improvements regarding MAC header protection (MHP), which involves key derivation and frame format. Regarding key derivation, technical solutions may include the use of a single key (TK) programmed into the hardware, from which the K-Header and K-Body can be derived. MHP can be used for MAC header protection, so that the current solution can use IV-body, including adding, defining and using the current security header (IV) and IV-header for the frame (body). This approach can simplify key management and reduce hardware memory characteristics. Frame formatting may include a combined MIC, IV-Header and ICV-Header configuration that takes into account header protection, body decryption and integrated MIC support. A public vote may be conducted to measure support for these proposed enhancements, addressing key derivation methods, frame format preferences, and the use of IV-Body for indicating MHP and ICV configurations.

[0175] For example, MHP can be used for MAC header protection, including improvements to key derivation and frame format. In terms of frame format, there may be options such as a fixed format with a combined MIC or with an initialization vector for the header (IV-Header) and an integrity check value for the header (ICV-Header) (MIC). A smaller PN for the header may be used, and an indication in a reserved field of the IV-Body may be utilized, such as 1 byte. The additional authentication data (AAD) for the ICV-Header may include the original packet number (PN-Orig), but it should be noted that a smaller PN may not support header encryption.

[0176] Key derivation may involve more or less consistency with different keys. Using the same key may be implemented, but it may involve additional designation work, for example, due to different counter constructions. One key may be programmed into the hardware, intended to prevent an increase in hardware memory for keys on the access point. For example, a single TK may be programmed into the hardware, and both the K-Body and K-Header may be derived using a single AES (ECB) operation, thereby leveraging existing hardware support for AES. The K-Body and K-Header may be derived and programmed into the hardware. The Pairwise Master Key (PMK) may not leave the supplicant / authenticator, and the hardware may not support hash calculations.

[0177] In the frame format, an example (e.g., option A) may contain <header> 、 <iv-body> 、 <c-body>and combined ICV / MIC. For the same body packet number (PN), the short PN of the header may potentially change. The header key can be calculated using the larger PN from IV-Body, where the formula is K_header = AES(TK, ("Header" || <fc>||<Body PN|| <j>)||...). Unlike random numbers, the body PN can be represented in little-endian format, and the key K_body for the body can be generated using AES (e.g., AES(TK,"Body"|| <j>)|| ...). The header replay check may use the 7-byte PN, concatenating the body PN with the short PN. The format options and short PN may be carried in the reserved bits in the body-IV. The combined ICV may be calculated by XORing the ICV-Header with the ICV-Body. The header additional authentication data (AAD) may include various parameters, but some parameters such as fc and seq may be masked in the body AAD. The header nonce may include A2 concatenated with the short PN.

[0178] For example (e.g., in option B), it may include <header> 、 <iv-body> 、 <c-body>and optional <iv-header>and <icv-header> <icv-body>This option allows separation of the IV Header and IV Body, where the IV Header is defined with a larger independent PN or Timestamp Field (TSF) as needed, without the need to encrypt any part of the header protection.

[0179] In the example, k_body can remain unchanged, so k_body is or acts as TK. For example, <fc>may not be used in K_header. For example, the header key in k_header may be made different for each frame. In some instances, K_header may derive the header key only once per TK. For example, if not bound to the header MIC / ICV, a malicious user may obstruct and mix two frames, e.g., a frame with a transmitted header PNi and a body PNj.<i,j> Frame: <1,1>, <2,2>, while a malicious user intercepts and sends <1,2>. For example, if the integrated MIC is not used, then <1,1> can be sent, but a malicious user can intercept and send <1,1> with a changed body. If the body MIC is not verified before acting on the header MIC, the sender state may conflict with the receiver state. For example, the technical solution may provide body PN binding using different means. For example, the technical solution may implement K_header = AES(TK,("Header" <j>)|| ... For example, the technical solution may use a minor variant of GCM (which is used by 11be) with a header nonce. For example, the technical solution may include or use A2||||<one byte short PN>||<block counter>. The short PN may be new; the block counter may be 3 bytes, as opposed to 4 bytes in standard GCM. In protectable content, there may be up to a power of 2 (**) 24, 16 byte blocks. Because the header may be small, different frames may have the same short PN but different BodyPN. The current IV may be used, as specified elsewhere herein.

[0180] Technical solutions may include implementations of combined integrated ICVs that may use body decryption before an acknowledgement (ACK) may be issued. This process may be implementation dependent, but certain implementations may be assumed and utilized accordingly. For example, the ACK process may not include completion of body processing. A Robust Secure Network Exchange (RSNXE) may advertise support for integrated MIC with MAC Header Protection (MHP), for example when both communicating endpoints support this functionality. Existing IV-Body reserved bits may be used as an indicator of the frame format being used.

[0181] The header ICV calculation may include calculating the header additional authentication data (AAD) without masking, and calculating the header nonce using a standard nonce format with a short PN or a packet number (PN) from an optional IV header. The header integrity check value (ICV) may be calculated using a CCMP / GCMP MAC algorithm, thereby combining the header key, header nonce, header AAD, and null data. Regarding the MHP bit, a value of 0x20 in the IV-Body [3] may indicate the use of MAC Header Protection (MHP), while 0x80 may indicate the use of an integrated message integrity code (MIC). When an integrated MIC is used, the absence of a set bit may indicate that the IV-Header and ICV-Header are separate. When an integrated MIC is used, a short PN may be represented by the IV-Body [2]. A technical solution may include or use a public vote. A public vote may include one or more queries regarding various aspects of the protocol. First, in Poll I, the vote or survey may involve a question about whether to support programming a key (TK) into hardware from which both the K-Header and K-Body can be derived. Participants can vote "Yes", "No", or "Abstain". For example, in Poll II, the focus may be on whether the frame format supports Integrated Integrity Check Values ​​(ICV). Similarly, participants can choose "Yes", "No", or "Abstain". For example, in Poll III, the use of IV Body to announce MAC Header Protection (MHP), Integrated ICV, the use of Shorter Header Packet Numbers (PN), and the presence of IV Headers may be queried. Similarly, participants can reply "Yes", "No", or "Abstain".

[0182] In one example, the message integrity code (MIC) may be retained in its current form while a modified version encrypted using AES is transmitted. Specifically, the transmission may include encrypting the MIC XORed with a timestamp field (TSF) using a specified key. Upon receipt, the recipient may decrypt the encrypted MIC and utilize the TSF or timestamp extracted from the beacon to access and verify the MIC, similar to the current process. This AES operation may be done for each beacon, which helps reduce processing of the entire beacon and repeatedly calculating the MIC.

[0183] When an element is referred to herein as being "connected" or "coupled" to another element, it is understood that the element may be directly connected or coupled to the other element, or that there may be intervening elements between the connected or coupled elements. Conversely, when an element is referred to as being "directly connected" or "directly coupled" to another element, it is understood that there may be no intervening elements in the "direct" connection between the elements. However, the presence of a direct connection does not exclude other connections in which there may be intervening elements.

[0184] References to "or" may be interpreted as inclusive, such that any term described using "or" may mean any of a single, more than one, and all of the described terms. References to at least one of a conjunction list of terms may be interpreted as inclusive or to indicate any of a single, more than one, and all of the described terms. For example, reference to "at least one of A and B" may include "only A," "only B," and both 'A' and 'B'. Such references used in conjunction with "includes" or its open terms may include additional items.

[0185] It should be noted that certain paragraphs of the present disclosure may refer to terms such as "first" and "second" in connection with a subset of transmission spatial streams, sounding frames, responses, and devices for the purpose of identifying or distinguishing one from another or others. These terms are not intended to relate entities (e.g., first substrate and second substrate) only in time or according to a sequence, although in some cases, these entities may include such a relationship. These terms also do not limit the number of possible entities (e.g., delay circuits, filters, peak detectors) that may operate in a system or environment. It should be understood that the above-described systems may provide multiples of any one or each of those components, and these components may be provided on independent structures or devices, or in some embodiments, on multiple structures or devices in a distributed system.

[0186] Although the above written description of the methods and systems enables one of ordinary skill in the art to make and use embodiments thereof, one of ordinary skill in the art will appreciate and understand that there are variations, combinations, and equivalents to the specific embodiments, methods, and examples herein. Therefore, the methods and systems of the present disclosure should not be limited to the above embodiments, methods, and examples, but should be limited to all embodiments and methods within the scope and spirit of the present disclosure.< / j> < / fc> < / icv-header> < / iv-body> < / header> < / j> < / j> < / fc> < / iv-body> < / header> < / nonce:13> < / flags:1> < / header> < / t-orig> < / c-body> < / iv-body> < / header> < / c-body> < / iv-body> < / c-header> < / iv-header> < / header> < / t-orig> < / c-body> < / iv-body> < / t-header> < / c-header> < / iv-header> < / header>

Claims

1. A system comprising: One or more processors coupled to the memory to: Calculating a first key for the body of a frame and a second key for a header of the frame using a temporary key TK programmed in hardware, the second key being different from the first key; encrypting the body of the frame at a machine access control (MAC) layer using the first key, and encrypting the header of the frame at the MAC layer using the second key; calculating a first message integrity code MIC of the encrypted frame using the first key, and calculating a second MIC of the content of the header of the frame at the MAC layer using the second key; and The frame having the first MIC and the second MIC is transmitted to a receiver, the receiver being configured to determine integrity of the header of the frame based at least on the second MIC.

2. The system of claim 1 , comprising the one or more processors to: generating a combined MIC from the first MIC and the second MIC; and The combined MIC is transmitted to the recipient to determine the integrity of the frame.

3. The system of claim 2, wherein the combined MIC is generated using a reversible operation applied to the first MIC and the second MIC, wherein the reversible operation comprises at least one of: a concatenation of the first MIC and the second MIC or a bitwise exclusive-OR (XOR) calculation applied to the first MIC and the second MIC. 4 . The system of claim 2 , wherein the combined MIC is generated using one of: a concatenation of the first MIC and the second MIC, a bitwise exclusive-OR (XOR) calculation applied to the first MIC and the second MIC.

5. The system of claim 1 , comprising the one or more processors to: Calculating the first key using at least one of a Hash-based Message Authentication Code (HMAC) operation or an Advanced Encryption Standard (AES) encryption operation having a first input of the TK and a first fixed pattern; and The second key is calculated using the HMAC operation with a second input of the TK and a second fixed pattern.

6. The system of claim 5, wherein the first fixed pattern includes at least a portion of the content of the body of the frame, and the second fixed pattern includes a packet number PN of the body of the frame, a type of the frame, or a link address for multi-link communication.

7. The system of claim 1, wherein the frame corresponds to a first network packet of a plurality of network packets, the first network packet comprising a first packet number in the header of the frame, the system comprising the one or more processors to: determining to resend the first network packet as a second network packet having a second packet number in a second header of a second frame of the second network packet, the second packet number being different from the first packet number; and A first key for a second body of the second frame of the second network packet and a second key for the second header of the second frame are calculated using the TK, the first key of the first network packet being different from the first key of the second network packet.

8. The system of claim 7, wherein the first key for the second body of the second frame of the second network packet is the same as the first key for the body of the frame of the first network packet, the system comprising the one or more processors to: identifying one or more frames to be encrypted at the MAC layer for wireless communication; and The second frame of the second network packet is encrypted at the MAC layer using the first key for the second body and the second key for the second header.

9. The system of claim 1, comprising the one or more processors to: determining a pairwise master key PMK during an exchange over a wireless network between a device including the one or more processors and a recipient; and The temporary key TK is generated using the PMK.

10. The system of claim 1, wherein the receiver is further configured to determine the integrity of the header based on verification of the integrity of the header using the second MIC before decrypting the frame.

11. The system of claim 1 , comprising the one or more processors to: including the second MIC in the header of the frame; and The frame is transmitted with the second MIC included in the header of the frame.

12. The system of claim 1 , comprising the one or more processors to calculate at least one of the first key or the second key using an Advanced Encryption Standard (AES) algorithm, and to calculate at least one of the first MIC or the second MIC using at least one of a Cipher Block Chaining-MAC Protocol (CCMP) or a Galois / Counter Mode Protocol (GCMP).

13. The system of claim 1, wherein the receiver is configured to verify the integrity of the header of the frame using the second MIC before processing the body of the frame.

14. A method for providing protection of a Machine Access Control (MAC) header of a frame, the method comprising: identifying, by one or more processors, a temporary key TK programmed in hardware to encrypt frames at a machine access control MAC layer for wireless communication; computing, by the one or more processors, a first key for encrypting a body of a frame and a second key for encrypting a header of the frame using the TK, the second key being different from the first key; identifying, by the one or more processors, one or more frames to be encrypted at the MAC layer for wireless communication; The body of the one or more frames at the MAC layer is encrypted using the first key, and the header of the one or more frames at the MAC layer is encrypted using the second key, by the one or more processors.

15. The method according to claim 14, comprising: calculating, by the one or more processors, a first message integrity code MIC of the encrypted frame using the first key and calculating a second MIC of content of the header of the frame at the MAC layer using the second key; and The frame having the first MIC and the second MIC is transmitted, by the one or more processors, to a receiver, the receiver being configured to determine integrity of the header of the frame based at least on the second MIC.

16. The method according to claim 14, further comprising: calculating, by the one or more processors, the first key using at least one of a hash-based message authentication code (HMAC) operation or an Advanced Encryption Standard (AES) encryption with a first input of the TK and a first fixed pattern; and The second key is calculated by the one or more processors using an HMAC operation with a second input of the TK and a second fixed pattern, wherein the first fixed pattern includes at least a portion of the content of the body of the frame, and the second fixed pattern includes a packet number PN of the body of the frame, a type of the frame, or a link address for multi-link communication.

17. The method of claim 14, wherein the frame corresponds to a first network packet of a plurality of network packets, The first network packet includes a first packet number in the header of the frame, the method comprising: determining, by the one or more processors, to resend the first network packet as a second network packet having a second packet number in a second header of a second frame of the second network packet, the second packet number being different from the first packet number; calculating, by the one or more processors, a first key for a second body of the second frame of the second network packet and a second key for the second header of the second frame using the TK, the first key of the first network packet being different from the first key of the second network packet, wherein the first key for the second body of the second frame of the second network packet is the same as the first key for the body of the frame of the first network packet; identifying, by the one or more processors, one or more frames to be encrypted at the MAC layer for wireless communication; and The second frame of the second network packet is encrypted at the MAC layer by the one or more processors using the first key for the second body and the second key for the second header.

18. The method according to claim 14, comprising: calculating, by the one or more processors, the first key for the body using an Advanced Encryption Standard (AES) operation with a first input of the TK and a first fixed pattern, and calculating the second key for the header of the frame using the same AES operation with a second input of the TK and a second fixed pattern; and The second key for the header is calculated by the one or more processors using the AES operation with a first input of the TK and a first fixed pattern, and the TK is used as the first key for the body of the frame.

19. The method according to claim 14, comprising: Generate an initialization vector IV for encryption based on the parameters of the frame; and The IV is used to encrypt the body of the frame.

20. A system comprising: One or more processors coupled to the memory to: Identify a temporary key TK programmed in hardware to encrypt frames at the machine access control MAC layer for wireless communication; using the TK to calculate a first key for encrypting a body of a frame and a second key for encrypting a header of the frame, the second key being different from the first key; identifying one or more frames to be encrypted at the MAC layer for wireless communication; The body of the one or more frames is encrypted at the MAC layer using the first key, and the header of the one or more frames is encrypted at the MAC layer using the second key.

Images